Introduced a new object tuple_chunk: a memory allocation is
associated with given tuple. tuple_format's vtab is extended
with few new methods to manage tuple_chunks lifecycle.
Implemented corresponding methid for memtx engine: a memory
chunks are allocated with memtx's smalloc allocator.

Needed for #1260

Needed for #1260

@TarantoolBot document
Title: A new option is_multikey for function definition

A new option is_multikey allows to specify wether new function
returns multiple values packed in a table object. This is a
native way to define multikey func_index.

The problem was that a tagged revision is not deployed, so after a
release we did an empty commit to trigger deployment. Now it is worked
around by adding extra deployment rules that deploys tagged revisions.
The workaround was suggested by Hiro Asari in [1].

[1]: https://github.com/travis-ci/travis-ci/issues/7780#issuecomment-302389370

Fixes #3745.

Due to the new 7.65.3 curl version released on 2019-07-19,
removed temporary workaround that downgraded the curl to
7.65.0.

This reverts commit 2e880af0.

Follows up #4288

Update the signature of space_build_index wrapper instead.

If any sub-set of fields indexed by a unique index is indexed by another
unique index, we can skip the uniqueness check for it. We use this to
optimize out unnecessary uniqueness checks in vinyl, where they may be
pretty costly, especially if the bloom filter doesn't reflect them.

Currently, whether to check if an index is unique or not is determined
in vinyl space constructor, which sets vy_lsm::check_is_unique flag for
the space indexes. This looks ugly, because this means that no other
engine can make use of this optimization without duplicating the code
setting up the flags. True, no other engine needs it now, but still it
doesn't feel right. Besides, the check_is_unique flag isn't actually an
index property - it's rather a property of a space so storing it in
vy_lsm looks wrong. Because of that we have to update the flag when an
index is reassigned to another space by MoveIndex DDL operation, see
vinyl_space_swap_index().

So let's store the flags indicating whether a uniqueness check is
required for a particular index in a bitmap in the space struct and
set it up in the generic space constructor, space_create().

When an index definition is modified by DDL in such a way that doesn't
require index rebuild (e.g. a key part type is changed from unsigned to
integer), we move the index from the old space container to the new one,
see ModifyIndex. In case of Vinyl we also need to update key definitions
and options stored in vy_lsm. We do that in swap_index space method, but
this isn't entirely correct, as this method is also called when an index
is moved without any modifications, see MoveIndex. Let's do this from
update_def index method instead, which seems to be more suitable.

The only reason this code lives in swap_index space method now is that
we didn't have update_def index method when this functionality was
introduced in the first place.

We may write to txn->sub_stmt_begin[TXN_SUB_STMT_MAX] so the array size
must be TXN_SUB_STMT_MAX+1 (see txn_begin_stmt). This didn't lead to any
problems, because we would only overwrite txn::signature, which wouldn't
break anything. However, should we change the txn struct, we could get
an unexpected error or even a crash.

Function memtx_tree_index_build_array_deduplicate worked
incorrectly: when build_array is empty it changed it size to 1.

Follow up #1257
Needed for #1260

It is convential to prefix boolean predicates with _is_.

Renamed memtx_tree_delete_identical to memtx_tree_delete_value
because it is a more descriptive name. Changed its signature
to return a deleted item, because this item may require an own
destruction.
This refactoring is required in scope of functional indexes.

Needed for #1260

Updated multikey memtx_tree methods a bit to make possible to
reuse them in case of functional indexes. The BPS_TREE_IDENTICAL
is only used in bps_tree_delete_identical (when BPS_TREE_NO_DEBUG
macro is defined) therefore it may be reused to delete an
identical entry in case of functional index in further patches.

Needed for #1260

Build serpent using a symlink to not clog third party with build
artefacts.

Fix a typo in naming, use a bit more verbose names..

@TarantoolBot document
Title: > require('console').set_default_output("lua")

A user might need to use lua output as default serializer so instead
of requiring him setting up the output every new session that named
default output mode may be used instead with help of command

Also we provide

 > require('console').get_default_output()

to obtain current setting.

Part-of #3834

Without this option serpent tries to encode function body,
making output a plain mess. So just like for yaml output
where functions are represented as

 | "completion_handler: 'function: 0x4074c910'

for lua output we will have

 | completion_handler = function() --[[..skipped..]] end,

Part-of #3834

@TarantoolBot document
Title: document \set output lua

Historically we use YAML format to print results of operation to
a console. Moreover our test engine is aiming YAML as a primary format
to compare results of test runs. Still we need an ability to print
results in a different fasion, in particular one may need to use
the console in a REPL way so that the results would be copied and
pased back to further processing.

For this sake we introduce that named "output" command which allows
to specify which exactly output format to use. Currently only yaml
and lua formats are supported.

To specify lua output format type

 | tarantool> \set output lua

in the console. lua mode supports line oriented output (default) or
block mode.

For example

 | tarantool> a={1,2,3}
 | tarantool> a
 | ---
 | - - 1
 |   - 2
 |   - 3
 | ...
 | tarantool> \set output lua
 | true
 | tarantool> a
 | {1, 2, 3}
 | tarantool> \set output lua,block
 | true
 | tarantool> a
 | {
 |   1,
 |   2,
 |   3
 | }

By default YAML output format is kept for now, simply to not
break the test engine. The output is bound to a session, thus every
new session should setup own conversion if needed.

Since serializing lua data is not a trivial task we use "serpent"
third party module to convert data.

Part-of #3834

We will use it for Lua console output format serialization

Part-of #3834

In contrast to subsequent calls, the initial call to box.cfg didn't log
configuration changes to the default state. As a result, by looking at
a log file we coudn't tell which configuration was being used.

Closes #4236

If CHECK constraint is added using ALTER TABLE statement, row_count
should be incremented. Note that row_count does not increase if CHECK
constraint is created during the execution of CREATE TABLE statement.
For example:

box.execute('CREATE TABLE t1(id INTEGER PRIMARY KEY);')
box.execute('ALTER TABLE t1 ADD CONSTRAINT ck1 CHECK(id > 0);')

Should return:
- row_count: 1

However, prior to this patch it was always equal to zero. Let's fix
this passing appropriate flag to OP_SInsert opcode.

Closes #4363

After we fixed bundled libyaml to correctly print 4-byte Unicode
characters, it is no longer compatible with the upstream version, so
enable building with bundled libyaml for every platform.
This way the tests will pass.

Follow-up #4090

If INSERT statement is executed with IGNORE error action (i.e.
INSERT OR IGNORE ...), it will return number of rows inserted.
For example:

CREATE TABLE t (i INT PRIMARY KEY, a INT check (a > 0));
INSERT OR IGNORE INTO t VALUES (1, 1), (2, -1), (3, 2);

Should return:
---
- row_count: 2
...

However it was three before this patch. So, let's account number
of successful insertions in case of INSERT OR IGNORE.

Follow-up #4188

VDBE was added to TXN because the generated identifiers were added
to VDBE in the sequence_next() function. Since they are now stored
in the VDBE itself, it is not necessary to have it in TXN.

Follow-up #4188

Currently, if an INSERT is executed inside SQL trigger and it
results in generated autoincrement identifiers, ones will be
displayed as a result of the statement. This is wrong, since we
are not able to divide IDs obtained into those that belong to the
table mentioned in the statement and those that do not belong to
this table. This has been fixed by adding a new argument to
OP_IdxInsert. In case the argument is not 0, recently generated
identifier is retrieved and saved into the list, which is held in
VDBE itself. Note that from now we don't save autoincremented
value to VDBE right in sequence_next() - this operation is moved
to OP_IdxInsert. So that, VDBE can be removed from struct txn.

For example:
box.execute('CREATE TABLE t1 (i INT PRIMARY KEY AUTOINCREMENT);')
box.execute('CREATE TABLE t2 (i INT PRIMARY KEY AUTOINCREMENT);')
box.execute('CREATE TRIGGER r AFTER INSERT ON t1 FOR EACH ROW '..
            'BEGIN INSERT INTO t2 VALUES (null); END')
box.execute('INSERT INTO t2 VALUES (100);')
box.execute('INSERT INTO t1 VALUES (NULL), (NULL), (NULL);')

Result should be:
---
- autoincrement_ids:
  - 1
  - 2
  - 3
  row_count: 3
...

Closes #4188

Currently, if we perform something like
CREATE TABLE t1 (
        s1 INTEGER PRIMARY KEY AUTOINCREMENT,
        s2 INTEGER,
        CHECK (s1 <> 19)
);
INSERT INTO t1 VALUES (18, NULL);
INSERT INTO t1 (s2) VALUES (NULL);

we generate a new identifier in VDBE, but in any other case we
generate it in BOX. That was needed since the CHECK did not work
properly. This is not necessary now, because CHECK was moved to
BOX due to issue #3691. After this patch all new identifiers will
be generated in BOX.

Part of #4188

Since all preparations concerning internal handling of unsigned values
have been done, now nothing prevents us from using UNSIGNED type in SQL.
This patch allows to specify UNSIGNED as a column type and adds CAST
rules, which are the same as for casual INTEGER, but with additional
check - result must be positive. Otherwise, error is raised.

Closes #4015

This patch allows to operate on integer values in range [2^63, 2^64 - 1]
It means that:
 - One can use literals from 9223372036854775808 to 18446744073709551615
 - One can pass values from mentioned range to bindings
 - One can insert and select values from mentioned range

Support of built-in functions and operators has been introduced in
previous patches.

Closes #3810
Part of #4015

As a part of introduction unsigned type in SQL, let's patch all built-in
function to make them accept and operate on unsigned value, i.e. values
which come with MEM_UInt VDBE memory type.

Part of #3810
Part of #4015

Let's patch internal VDBE routines which add, subtract, multiply, divide
and calculate the remainder of division to allow them take operands of
unsigned type. In this respect, each operator now accepts signs of both
operands and return sign of result.

Part of #3810
Part of #4015

As it was stated in the previous commit message, we are going to support
operations on unsigned values. Since unsigned and signed integers have
different memory representations, to provide correct results of
arithmetic operations we should be able to tell whether value is signed
or not.
This patch introduces new type of value placed in VDBE memory cell -
MEM_UInt. This flag means that value is integer and greater than zero,
hence can be fitted in range [0, 2^64 - 1]. Such approach would make
further replacing MEM_* flags with MP_ format types quite easy: during
decoding and encoding msgpack we assume that negative integers have
MP_INT type and positive - MP_UINT. We also add and refactor several
auxiliary helpers to operate on integers. Note that current changes
don't add ability to operate on unsigned integers - it is still
unavailable.

Needed for #3810
Needed for #4015

This routine implements obsolete mechanism to retrieve default column
value. Since it is not used anymore, let's remove it. Note that related
functions valieFromExpr()/valueFromFunction() are not erased since they
look pretty useful and may be involved later.

OP_OffsetLimit instruction calculates sum of OFFSET and LIMIT values
when they are present. This sum serves as a counter of entries to be
inserted to temporary space during VDBE execution. Consider query like:

SELECT * FROM t ORDER BY x LIMIT 5 OFFSET 2;

To perform ordering alongside with applying limit and offset
restrictions, first 7 (5 + 2) entries are inserted into temporary space.
They are sorted and then first two tuples are skipped according to offset
clause. The rest tuples from temporary space get to result set.

When sum of LIMIT and OFFSET values is big enough to cause integer
overflow, we can't apply this approach. Previously, counter was simply
set to -1 which means that all entries from base table will be transferred
to ephemeral space. As a result, LIMIT clause was ignored and the result
of query would be incorrect. Motivation for this obviously wrong step was
that to perform query with such huge limit and offset values too many time
is required (like years). What is more, ephemeral spaces support
auto-generated IDs in the range up to 2^32, so there's even no opportunity
to process such queries in theory. Nevertheless, to make code cleaner
let's fix this tricky place and just raise an overflow error if result
of addition exceeds integer range.

This patch fixes obsolete comments saying that in case of overflow
execution won't stop; now limit and offset counter are always >= 0, so
removed redundant branching.

We are going to allow using unsigned values in SQL and extend range of
INTEGER type. Hence, we should be able to parse and operate on integers
in range of [2^63, 2^64 - 1]. Current mechanism which involves
sql_atoi64() function doesn't allow this.

Let's refactor this function: firstly, get rid of manual parsing and use
strtoll() and strtoull() functions from standard library. Then, let's
return sign of parsed literal. In case of success now function returns 0,
-1 otherwise.

This patch also inlines sql_dec_or_hex_to_i64() to place of its only
usage: it makes code cleaner and more straightforward.

Needed for #3810
Needed for #4015

Fixes decimal.round() with zero scale, fixes an error with
decimal.round() when rounding leads to a number with the same
precision, for example, decimal.round(9.9, 0) -> 10.

Follow-up #692

This patch adds 2 methods to decimal library and lua module:
trim will remove all trailing fractional zeros and rescale will
either perform rounding or append excess fractional zeros.

Closes #4372

@TarantoolBot document
Title: document 2 new functions in decimal Lua module

2 new functions are added to the decimal module:
`decimal.trim()` and `decimal.rescale()`

`decimal.trim()` removes any trailing fractional zeros from the
number:
```
tarantool> a = dec.new('123.45570000')
---
...
tarantool> decimal.trim(a)
---
- '123.4557'
...
```
`decimal.rescale()` will round the number to a given scale, if it is
less than the number scale. Otherwise it will append trailing fractional
zeros, so that the resulting number scale will be the same as the given
one.
```
tarantool> a = dec.new(123.45)
---
...
tarantool> dec.rescale(a,1)
---
- '123.5'
...
tarantool> dec.rescale(a, 4)
---
- '123.4500'
...
```

pretest_clean: extended a list of predefined functions with registered
SQL builtins and persistent Lua function 'LUA'.

Follows up #4182.

Enabled complete testing for OSX, temporary skipped the
failed suite replication/ and tests engine/replica_join
with issue #4370 and small/quota from repository
https://github.com/tarantool/small.git with issue #4357
to enable it back. Also fixed the OSX ulimit setup
different for VBOX and Travis-ci images.

Closes #4358