Add caching of sharding function

[0x501D]

The ddl.bucket_id() function needs to know a sharding function.
It is costly to obtain the function declaration /
definition stored in the _ddl_sharding_func space.

Cache contains:
raw_tuple - raw sharding metadata, used for get_schema()
parsed_func_name - parsed dot notation (like {'foo', 'bar'})
callable - function ready to call, this offloads using of loadstring()
error - string with an error: not nil only if setting callable fails

Cache will be rebuilded if:

• _ddl_sharding_func space changed: cache sets _ddl_sharding_func:on_replace
  trigger
• schema changed: cache checks box.internal.schema_version changes

This patch does not serve hot reload techniques.
This entails an on_replace trigger duplication if hot reload occurs.
Hot reload support will be done in separate task:
#87

Benchmarks - 10000000 bucket_id() calls (file test/bench_cache.lua):
Baseline (no DDL): 3.38s user 0.01s system 99% cpu 3.389 total
After this patch:
DDL with function body: 3.81s user 0.01s system 99% cpu 3.818 total
DDL with function name: 5.49s user 0.00s system 99% cpu 5.495 total
Before patch:
DDL with function body: 55.95s user 0.40s system 99% cpu 56.354 total
DDL with function name: 13.68s user 0.13s system 99% cpu 13.807 total

Closes #82

[ligurio]

Thanks for the patch! See my comments inline.

Also please add a 'Closes #82' to commit message and a number of issue to PR description.

[Totktonada]

Since we aim to resolve a performance problem here I would like to see some performance measurements. For example, the following:

• Baseline: just call our own bucket_id function directly (I suggest to extract mpcrc32 from vshard).
• Bad case: call ddl.bucket_id() before this patch (name / body).
• Good case: call it after the patch (name / body).

It would be good to commit the microbenchmark right into the repository with a short instruction.

If the good case is not so good, we can look a bit deeper and, say, check, whether implementing a fast path for a function that is placed directly in _G will change the situation (here we don't need a loop to extract a nested field with the function). Or, maybe, we'll spot other problematic places. Or, in turn, we can see that the caching does not give anything (I would be surprised, but anyway).

[ligurio]

Thanks for your fixes!

In general everything is fine, however I left several non-critical comments. Please consider them. I will give an LGTM to don't block merge.

[Totktonada]

LGTM.

Please, address stylistic suggestions from Sergey, squash (or rework-and-squash) the proposed commit into your one and let me know that everything is done.