Fixes gh-2516 New SQL data types and function changes

[pgulutzan]

Issue #2516 is intended as a fix for
Issue #2406 Literals for INTEGER, DECIMAL and DOUBLE
Issue #2439 SUBSTR() function
Issue #2440 Field type ANY in SQL
Issue #2455 Default types of SQL built-in functions
Issue #2461 Field type ARRAY in SQL
Issue #2462 Field type MAP in SQL
Issue #2475 Syntax for ARRAY in SQL
Probably reviewers will include @ImeevMA and @NickVolynkin.
Probably there will be several commits so consider this a first draft.
A possible controversial point is that I introduced arrays and maps in a section about literals rather than a later section about expressions -- putting them later would require some reorganizing.
UPDATE (2022-02-07): This is no longer a draft, so reviewer @ImeevMA can look at it whenever it's convenient.

[ImeevMA]

Hi, @pgulutzan! I will review this PR. I also want to say that there will be a few more patches related to MAP and ARRAY. There will be a patch that adds a syntax for MAP values, patches that fix an error when MAP or ARRAY is used in ORDER BY/GROUP BY, and patches that fix some problems with using MAP and ARRAY in C user-defined functions. Also, it's possible that I will find more problems.

[pgulutzan]

@ImeevMA: "A possible controversial point is that I introduced arrays and maps in a section about literals rather than a later section about expressions -- putting them later would require some reorganizing." What is your opinion?
By the way, I will make small style changes too, for example now we should if possible avoid saying "we" in the manual.
Update (a few days later): Never mind, I decided to try saying map and array literals are simple things that contain only a literal, and make a forward reference to map and array expressions which come later. The description of maps comes from from branch imeevma/gh-4763-syntax-for-map, not branch master (I don't see map expressions in branch master yet), and I added a mention that arrays can have integer indexes, which is purely a guess.

[pgulutzan]

@patiencedaur:

In sql_plus_lua.rst, examples that work in earlier versions will fail in Tarantool version 2.10.0.
So I'm adding comments in the code to tell users what to do if they have earlier versions.
For example:

.. code-block:: lua

box.schema.func.create('_DECODE',
   {language = 'LUA',
    returns = 'string',
    body = [[function (field, key)
             -- If Tarantool version < 2.10.0, replace next line with
             -- return require('msgpack').decode(field)[key]
             return field[key]
             end]],
    is_sandboxed = false,
    -- If Tarantool version < 2.10.0, replace next line with
    -- param_list = {'string', 'string'},
    param_list = {'map', 'string'},
    exports = {'LUA', 'SQL'},
    is_deterministic = true})

The comments should be translated for the Russian manual.
Alternative 1: Duplicate every example so there's an old and a new version.
Alternative 2: Put the instructions outside, and refer to line numbers.
If you like one of the alternatives,
or if you have a better idea,
we'll do whatever you prefer.

[patiencedaur]

@pgulutzan Yes, let's do what you suggest. Thanks for letting me know.

[ImeevMA]

Hi! Thanks for the patch-set. I have a few comments below, but nothing major. I only reviewed the part about MAP and ARRAY.

[ImeevMA]

I think {} can be considered smaller than {'':''}.

[ImeevMA]

I think we should add that ANY values are not comparable (SCALAR values are comparable).

[ImeevMA]

I think here should be {UUID(): (SELECT 1) + 1}. Also, I think we should add some examples of MAP values where there is more than one key-value pairs, for example: {1:'a123', 'two':uuid()}.

[ImeevMA]

I think we should add that the value can also be a MAP, so MAPs can be nested (as was done for ARRAY).

[ImeevMA]

I think we should expand this part to include [] for MAP. Or it should be dropped, since the patch is currently in review: tarantool/tarantool#7140