tuple_update() now accepts a MsgPack array
of arrays, each array - an update operation.

Fix a bug with wrong calculation of splice
new field length in update.

Fix a bug in test-suite.py where it would
wrongly drop core files after a server crash.

Convert the entire test suite to the new
update.

Misc cleanup:
Rename UPDATE_OP enum, drop the define.
Update tests.
Now that there is always a new destination,
we don't need a temporary buffer for splice or
anything else. Remove it.
Remove works_in_place, since it was also necessary only
to support multiple operations.
Update comments.

field->compact in Lua field used to be memset() to false.
I removed the memset since it's wasted cycles in 99% of cases,
but did not add an explicit initialization of field->compact
to LUA_TTABLE case, which uses it. By default, field->compact
must be set to false, and only for tuples it should be true.

In Lua, by definition, an array is something that
is indexed from 1 and doesn't have gaps in indexes.

This can be easily checked without serializer hints.

Tuple to YAML conversion should not go through a temporary
conversion to a Lua table in the future, so it should
also not be an argument for slowing things down.

Use the constants consistently across the code base.

This patch merges row_header and wal_row structures into new
log_row structures.

Change box.error to push error codes without error flags.

Update the protoco spec in doc/box-protocol.txt.
Update box.net.box with a bunch of hacks.
Update the python driver.

Remove support for flags variable (BOX_RETURN_TUPLE).
It was not tested anywhere! (-> kill)

Implemeng Lua msgpack.next() to support streamed processing.
Add tests.

Fix a bug with messed up aliases of msgpack.dumps() pointing
to encode() and loads() pointing to decode() (should be vice versa).

Introduce constants for ids. Update tests.

Conflicts:
	src/box/tree_index.cc
	src/box/tree_index.h
	test/big/tarantool.cfg
	test/box/errinj.result

fixes, follows from discussion https://github.com/tarantool/tarantool/issues/79#issuecomment-29309533