Implement the picodata engine for sbroad to integrate distributed
SQL into the picodata binary. In fact, picodata engine simple
exports public rust functions from api.rs. On the picodata side
they (and some lua functions) are imported and included into the
bunary on the build phase.

Current commit is POC and have some problems:
- DDL is still not implemented in the picodata (_pico_space is mocked);
- we include tarantool module symbols twice (first time in sbroad,
  second time in picodata binary);

But anyway, it works and all these problems should be solved in the
next commits.

Implement opentelemetry instrumentation in sbroad.
How to test:

docker run --name jaeger -d --rm -p6831:6831/udp -p6832:6832/udp \
-p16686:16686 -p14268:14268 jaegertracing/all-in-one:latest

Then run a stress test with sbroad. The results would be available
at http://localhost:16686/

Previously, we created a static archives of the msgpuck and decNumber
libraries and made a statically linked them into the test executable.
After tarrantool module migrated to dlsym, we can no longer use static
linking.

As a result we build shared libraries for msgpuck and decNumber to
dynamic link them into the unit test binary.

As a side effect we got rid of the environment variable in a unit
tests build. Now we rely of a feature "mock" for this purpose.

picodata features enables Picodata Tarantool fork functionality
Schema enables functionality needed to operate spaces metadata

This reverts commit d9b2f822.
Cargo.lock is now included in repo, so no need to fix version to get
reproducible build

We migrate from the `decimal` crate (used decQuad from decNumber
to store the numbers) to Tarantool internal types provided by the
Rust module. The reason was to make IR numeric values easy
serializable to the query parameters (a part of the executor
refactoring).

The problem with Tarantool internal types is that the internal
decNumber representation is provided by Tarantool ABI. So we always
need Tarantool itself to use the types. It is ok for integration
tests, but for unit tests with `cargo test` it is a problem. As a
solution we have implemented some mocking infrastructure to build
a static library based on the Tarantool decNumber, MsgPuck and some
wrappers over them both to make unit tests work.

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.

Old code was removed. Integration tests was adopted to new executor

BREAKING CHANGE: move from branch-based references in the tuple to
the array-based. Also add a logical ID to all relational nodes and
keep it in all its child tuples.

Now, our reference coordination system in a tuple looks like:
- parent relational node logical ID (we don't know actual position
  in the nodes list, so use "secondary index")
- target - i.e. a position of the reffered node in the relational
  node's children list
- posirtion in the reffered relational child node output tuple

Migration to tarantool module master branch for more conformable working
with Lua calls.

We expect that every relational node contains a reference to the
row expression node, that contains only aliases (expressions with
names). We need this convention to simplify SQL -> IR transformation.

At the moment IR (logical plan) is far from final release. Current
commit fixes some point on a way to the final API and full test
coverage.

1. Implement columns (with types) and tables as a part of IR.
2. Use serde deserialization trait to build tables from YAML files.
   It would be also helpful when writing tests for arbitrary plan
   transformations.

To work with Calcite and Tarantool the planner needs to store values
in the plan leaf nodes. These values should be defined with exact types.
At the moment we need only several primitive types:
- boolean
- null
- number (decimal from decnumber library)
- string

As the planner analyzes SQL, it has to work with tree-valued logic
(3VL). At the moment we'll need only equivalence operation, so it
was implemented for the values in a 3VL manner.