When we gathered SQs we traversed only a subset of relational
nodes in `rel_iter`, because in `rel_iter` we didn't go into
children that are located in `filter` or `condition`. Now we
traverse all relational nodes in the plan.

Now if the subplan has Buckets::All and have Segmented vtables,
then we will filter vtables

We had a problem with the queries like:

select * from t1 where (a, b) in (select c, d from ...)

The root of the problem was that in a case of multiple references
to the subquery ((a, b) in (ref_c_sq, ref_d_sq)) we tried to bind
parameters multiple times that caused subtraction overflow and UB.
As a fix we stop binding parameters more than once.

Co-authored-by: ms.evilhat <ms.evilhat@gmail.com>

Remove redundant transaction start from the open telemetry's spans
in the code. There is no sense in it at the moment (seems like it
was added while prototyping tarantool space as a storage for the
per-fiber traces... but we gave this idea up and switched to the
custom Rust implementation). But if we start a transaction manually
and call sbroad execute() method, we end up with transaction already
started error. So, remove the transaction start wrappers and make
nested transactions work.

The configuration cache is a part of the executor's runtime.
Previously, quech query was holding a immutable borrow of the
runtime, while cache invalidation tried to get a mutable borrow
(apply_config). As a result, the cache invalidation always failed
to mutably borrow the runtime.
Current commit fixes the issue by wrapping the configuration in
a reference cell. As a result, apply_config now immutably borrows
the runtime and don't fail on this step.

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.