We have a special `sysview` engine that bypasses transaction management
and reads right from memtx indexes. The problem is memtx indexes use
memtx MVCC by themselves, so despite `sysview` bypasses transaction
management process, it actually uses memtx MVCC. So the problem here is
that transaction can actually read something using `sysview`, a tracker
in MVCC will be allocated, but `txn->engine[memtx->id]` still will be
`NULL`, so the preparation of the transaction won't be finalized by
memtx_tx and the tracker won't be deleted when transaction is prepared.
On conflict, MVCC will try to abort that already prepared transaction
and it will lead to a crash.

Actually, crashing scenarios are rather synthetic and break only our
engine fuzzer. Here is an example of such scenario without manual use
of system spaces:
1. Open a transaction and do an operation in a vinyl space.
2. Try to alter the space in the same transaction - it will fail with
   cross-engine transaction error.
3. Commit the transaction, but do not wait for WAL write (internally,
   such state is called `prepared`).
4. Alter the space in another transaction and commit it before the
   previous transaction was written to WAL. Here MVCC will try to
   conflict that already prepared transaction and it will break
   Tarantool.

To solve the problem, we could try to write quite a large patch to handle
such transactions differently in memtx MVCC. But instead, let's simply
finalize prepare of all transaction in MVCC. The current design already
lacks encapsulation - all transactions (even non-memtx) are registered
there, so such solution not only simple but also consistent with other
MVCC parts. Note that memtx MVCC still can abort such non-memtx
transactions when they are in-progress, but it seems that such behavior
doesn't break other yielding engines (`vinyl` is the only one) - the
commit covers it with a simple test along the way.

In order not to do unnecessary function call when MVCC is disabled,
function `memtx_tx_prepare_finalize` is `static inline` now and uses a
`*_slow` helper when MVCC is actually enabled - such approach is common
in this subsystem.

Closes #10715

NO_DOC=bugfix