- add support for queries that use
union all operator with global tables
- for the case when global table is
used against sharded table, the global
table is materialized only on single
storage, on all other storages the
global child of union all is not
materialized

BREAKING CHANGE!: renamed __SBROAD_STAT into _sql_stat,
__SBROAD_QIERY into _sql_query.

1. _sql_stat primary key also includes the parent_span cause
   we support PG extended protocol and we need to bind same spans
   to different trees.
2. Fix some bugs in the telemetry for queries.

feat: add checks on table columns creation and insertion, add check on parameters number, add support of is_nullable metadata

When reading from multiple storages it is
possible that some requests will execute faster
than the others. And it could lead to wrong
results when vhard moved the buckets between
nodes.

For example: we execute `select * from t`
on storage 1 and get the results. Vshard
moves the data from storage 1 to stroage 2,
and then we execute `select * from t` and in
result we get the data (that moved) twice.

This commit fixes it by using vshard's
storage ref api. Now multi-node read requests
first create the ref on each node which
blocks vshard rebalancing. Then we call
our stored procedure and remove the ref.

- add support for new dml operator update
- subqueries are not allowed in update
expression.
- primary key columns can't be updated.
- update as other dml operations is
not atomic: it may fail on some
storages and succeed on others.

Picodata was bumped to rust 1.71.0, so sbroad as its submodule can
finally update the rust version as well.

Stored procedures creation with "box.schema.func.create" is essentially
an insert into a system space "_func". An attempt to call that API on
a replica (which usually is a RO instance) will result
in failure in role initialization.

BREAKING CHANGE!: local motion now means local materialization
of results on the storage without bucket calculation. The old
logic of "do nothing" was moved into none motion.

Implement delete SQL operator. It is always executed locally as we
delete already existing tuples and never change tuple buckets.
We reinvent the logic of the local motion policy (see the desclamer
in this commit) and materialize the primary keys from projection on
the storage. Then they are removed from the space via space API in
a single local transaction.

We need this information to perform delete and update operations
using space API in future.

Option sql_vdbe_max_steps stops long running
queries from blocking tx thread or queries that 
use too much memory during local execution. 

Each sql query is compiled into VDBE opcodes on storages. This
parameter sets max number of opcodes that VDBE
can execute.

Example: `select * from t option(sql_vdbe_max_steps=1000)`

Option vtable_max_rows limits the maximum number of rows in
virtual table. This limit is checked on storages before returning
intermediate results and on routers when receiving results from
storages.

Example: `select * from t option(vtable_max_rows=1000)`

* added HAVING clause. HAVING condition may contain aggregates. Any column outside aggregate function must be part of a grouping expression. 

E.g: `select sum(a) from t group by b having c > 1` Above query is invalid, because `c` is not a grouping expression.