After implementing cartridge sharding mock tests were mostly
useless: we didn't see how we modify SQL according to some specific
shard.

Now (in a case of the filtered buckets when we send a query to exact
shards) mock engine generates SQL for every shard. This behavior
differs from the cartridge engine that groups buckets by replicasets
first and then generated SQL for a replicaset bucket group. But the
idea of the mock engine is to detect errors but not to implement
actual Tarantool. So, lets make things simple and use this approach.

Previously we had a data sharding only on the planner side.

docs(README): state that Sbroad is an executor for `cartridge`-based cluster, because `vshard` cluster is required but not enough

Also added missed pretty_assertions to some of the tests in the
cartridge module.

At the moment all the query ASTs are cached in the engine LRU cache.
There is not much sense in it since we don't support parameters at
the moment, but it would be done later.

To get ready for parameters we have also added parameters support
in the grammar, but didn't implement it in the AST code.

At the moment our grammar doesn't support any sub-queries in the
projection list. So it is a waste of CPU resourcies to transform
projection lists (a big performance penalty for projections with
a huge amount of columns).

Previously for every query we hold a mutable reference on an engine
and tried to load a cluster metadata if the cache was empty. The
problem was that tarantool yields on a first query uploading the
cache to a new one, that also tries to get a mutable reference to
the engine.
The main problem was that we should never hold a mutable reference
to an object with a Lua code, that can be yielded by tarantool
(such behavior is opaque to the Rust compiler). To deal with it we
shrink a metadata upload to a list of separate methods. For the
ones that can yield we always hold an immutable reference. Those
methods that need a mutable reference to the engine never yield.

Basically callbre means that we call replicaset with two additional parameters:
    1) prefer_replica = true. We can use read from replicas because
        transactional consistency is out of Sbroad scope. Basically we
        do not care about data consistency at all.
    2) balance = true. This parameters enables internal vshard load
        balancing between replicaset nodes in round-robin fashion,
        with a preference for replicas if prefer_replica=true is also set