SERIALIZABLE transactions need to mark selected rows

Current implementation of SERIALIZABLE isolation level in MVStore should be valid for read-only transactions, but concurrent transactions with changes aren't guaranteed to have the same effect as their execution in order.

(Note that in all released versions of H2 this isolation level effectively works as READ COMMITTED, so it's not a regression for MVStore engine.)

1. SERIALIZABLE transaction should fail when it tries to update a row that was modified by another transaction. Such restriction should be simple to implement, we have a complete snapshot and can compare values.

2. SERIALIZABLE transaction with changes should not be able to commit its work if rows that were selected by this transaction were modified by another transaction. That's not that simple, perhaps such transaction should collect all accessed rows somewhere. As an alternative we may lock them all, but it will be very expensive and it will reduce scalability. Another serializable transaction may read the same rows, and if they weren't modified anywhere they may continue its work concurrently.

After either failure transaction can only be rolled back.

Start by tracing MVStore's SERIALIZABLE transaction implementation, including its complete snapshot and row-selection handling. Done means conflicting updates or selected-row modifications cause the transaction to fail and require rollback, while read-only transactions remain valid.