Add test coverage for complex multi-index update scenarios

Add test coverage for complex multi-index update scenarios.

1. Multiple unique indexes, a unique constraint violation on the second index.
2. UPDATE which changes field count and thus violates space arity constraint (cardinality).
3. Inject errors into write_to_disk when queue size is more than just one entry.
For that use multiple connections which all send update requests, block on a sync point,
then an error is injected, and they all are unblocked.
4. UPDATE modifies a tuple, is queued for wal_write, another UPDATE modifies the same tuple again, is queued, then the first UPDATE is rolled back (triggering a roll back of the subsequent UPDATE as well.
This case has sub-cases with REPLACE, DELETE and INSERT, SELECT and their combinations.
Another dimension of this problem is that transactions which modify a tuple in a completely different space get rolled back as well -- cover this with tests.
5. Same as 4, but a longer dependency chain: INSERT, UPDATE, DELETE, REPLACE, all on the same tuple, from parallel connections, all queued for a write to disk, and then failed.
6. write_to_disk failures can be of two kinds: bulk write failure or log rotation failure. Inject errors into both of these cases, and test the effect on long-dependency-chain updates.
7. Test demonstrating the differences between Tarantool REPLACE and MySQL REPLACE.
8. Show by test that currently we have 'dirty reads' for read-only transactions: they see INSERTs that have not reached the disk yet. Show the case of a such phantom in a test.
Possible phantoms:
- tuple which never existed
- update which never existed.
- delete which actually was rolled back, so the tuple *existed*, yet SELECT returns nothing.

This all must be covered for a case of the primary, secondary unique, and secndary non-unique index.
Cover plain SELECT and Lua iterators.