change implicit cast for assignment

[TarantoolBot]

After this patch, these rules will apply during the implicit cast:

	STRING	BINARY	BOOLEAN	INTEGER	UNSIGNED	DOUBLE
STRING	A	N	N	N	N	N
BINARY	N	A	N	N	N	N
BOOLEAN	N	N	A	N	N	N
INTEGER	N	N	N	A	S	Aa
UNSIGNED	N	N	N	A	A	Aa
DOUBLE	N	N	N	Sa	Sa	A

In this table, the types of the assigned value are on the left,
and the types that should be after the assignment are at the top.

'A' - the assignment will be completed.
'N' - the assignment won't be completed.
'S' - the appointment may be unsuccessful.
'a' - after assignment, the resulting value may be approximated.

Rules for numeric values are these:

1. Loss of significant digits (overflow) is an error.
2. Loss of insignificant digits is not an error.

Example:

tarantool> box.execute([[CREATE TABLE t1(i INT PRIMARY KEY);]])
tarantool> box.execute([[INSERT INTO t1 VALUES ('1');]])
---
- null
- 'Type mismatch: can not convert 1 to integer'
...

tarantool> box.execute('INSERT INTO t1 VALUES (1.2345);')
tarantool> box.execute('SELECT * FROM t1;')
---
- metadata:
  - name: I
    type: integer
  rows:
  - [1]
...

tarantool> box.execute([[CREATE TABLE t2(t text PRIMARY KEY);]])
tarantool> box.execute([[INSERT INTO t2 VALUES (1);]])
---
- null
- 'Type mismatch: can not convert 1 to string'
...

Requested by @ImeevMA in tarantool/tarantool@30c57bb.

[pgulutzan]

@lenkis: The significant matter is that implicit casts to/from
STRING/number are no longer legal.
I made the change in the version 2.5 manual.
I added a deprecation warning in the version 2.4 manual,
but only in the SQL section. I did not add a deprecation
warning elsewhere, because I expect that will happen
when the Release Notes section is updated.
This is correctly described in the Tarantool release announcement for 2.5.1 beta
"[Breaking change] Define new rules for implicit cast for assignment operation in SQL (gh-3809)."