We stop using VALUES to store temporary tuple on the storages and
switch to the tarantool spaces instead. This is done to avoid the
problems with the auto generated column names in VALUES, parser
stack and parameters limitations.

Tarantool forbids to use multiple space engines in a single transaction.
So for vinyl tables we have to use vinyl spaces as a tepmorary storage.
For memtx tables we can use temporary memtx spaces.

One more important change is that we can't insert values of
different numeric types in a number column (as we don't cast them
as the local SQL does).

Reduce the amount of the heap allocations (use recursion instead of
the heap stack).

We should not use the cache on the storage if the plan contains
virtual tables, as they can contain different amount of tuples that
are not taken into account when calculating the cache key.

Fixes: issue 308.

BREAKING CHANGE: api functions have changed signatures.

This commit changes the way how the router dispatches commands to
the storages. Previously, the router compiled the SQL statements
with parameters from the plan subtrees and sent them to the storages.

Now the router sends the raw IR subtrees to the storages.

1. The subtrees are constructed from the original plan nodes
   for performance reasons: the node's memory chunk is extracted
   from the original plan tree (replaced with invalid parameter node)
   and reused in the sub-plan.
2. The router-storage message consists of the two parts: required and
   optional. The required part is the hash of the sub-plan (excluding
   constants - analogue of the SQL pattern in the previous version)
   and parameters. The optional part is the IR itself and the syntax
   node tree (precompiled on the router to skip redundant work on the
   multiple storages). Storage uses a lazy deserialization of the message:
   - first it deserialized the part with the hash and parameters (to
     check the plan cache)
   - if the cache lookup failed, it deserializes the IR and the syntax
     node tree and updates the cache.
3. The SHA256 hash was replaced with BLAKE3 for performance reasons.

These traits are required to serialize IR to Lua and deserialize
it back to Rust while dispatching an execution plan to the storages.

Now IR supports only reading full array column witouth working with indexes

Explain should show the same version of the selection clause as we
use to build SQL.

Now we support a flashback traversal for the subtree iterator. As
a result we can traverse the original selections in a way they looked
before any transformations were applied. This solves the problem
of too verbose DNFs that can easily reach tarantool's parser stack
limit.

Split different traversal iterators to separate modules.

As we use an append-only arena for the plan, we can easily implement
an UNDO log for each transformation we make. It can be helpful when
we would like to undo any of the transformations.

The main goal of it now - to rewind transformed selection to the
original state, as it can produce a logically equivalent, but too
long SQL string that breaks tarantool parser on the storages.

We have already fixed the problems with the bucket_id system column
(fc8b6d93), but forgot to take care
of the join condition references. Now this problem is fixed.

Now sbroad has distributed SQL functions in the core crate. At the
momnet there is only a single implementation of the `bucket_id()`
function.