After a multikey index is altered or dropped, tuples that were inserted
while it existed still reference the format with multikey parts. Actually,
that multikey format field shouldn't be used anymore because multikey
index is gone, but that's not true. It happens because format is arranged
to a JSON tree, and this tree has an interesting property. Imagine having
a field with path '[1][*]' in the tree. Then, when looking for a field
'[1][1]' (or '[1]["abc"]', the second key can be anything), the field with
path '[1][*]' will be returned since '*' is actually wildcard. Hence,
even if the format is stale and there are no multikey fields in actual
format, we can obtain a multikey field even if we didn't search for it
and `multikey_idx` will be MULTIKEY_NONE in this case. Let's handle this
scenario - simply ignore offset slot when `multikey_idx` is MULTIKEY_NONE
for a multikey field.

This bug could lead to assertion failure in Debug build and UB or even
crash in Release build because when one builds an index over the field
that was covered by multikey index, field map of tuples referencing the
old format would be incorrect - it would store offset of multikey array
instead of actual field.

Closes tarantool#11291

NO_DOC=bugfix