sql: enable ephemeral index optimization

This patch enables "ephemeral index" optimization (which is called
Automatic Indexes in the original SQLite implementation). The main idea
behind the optimization is to create temporary (ephemeral) space that lasts
only the duration of single SQL statement. Such space stores intermediate
execution results. Since in Tarantool index can't exist without space
(in contrast to SQLite) we call this optimization "ephemeral index".
It may turn out beneficial due to the fact that cost of creating and
filling space with single index is (NlogN). So if we lookup data more
than logN times during the query execution, ephemeral index may give as
better timings (space full-scan is still O(N)).

As a rule "ephemeral index" space relates to one of spaces used in query
and contains all or fewer fields than the original space. The order of
fields in ephemeral space may be different from order in the original space.
In addition to the mentioned fields, ephemeral index has a rowid -
additional unsigned field with non-decreasing values which allows to
store not unique values.
Example:

CREATE TABLE t1 (i INT PRIMARY KEY, a INT, b INT, c INT);
CREATE TABLE t2 (i INT PRIMARY KEY, a INT, b INT, c INT);
...
SELECT t1.a, t2.b FROM t1, t2 WHERE t1.b = t2.c

In case the planner decides to use an ephemeral index and chooses t1 as
the source space, an ephemeral index with three fields will be created
and will contain the values from t1.b, t1.a, and rowid in that order.
If t2 is chosen as the source space, an ephemeral index will contain the
values from t2.c, t2.b, and rowid.

This optimization can also be applied to store results of subquery
evaluation.

Closes #4933

Co-authored-by: Mergen Imeev <imeevma@gmail.com>
Co-authored-by: Timur Safin <tsafin@tarantool.org>
Reviewed-by: Nikita Pettik <korablev@tarantool.org>