The tuple cache can store chains. If a read iterator sees a chain,
it may skip deeper sources assuming there's nothing there. The problem
with cache chains is that we don't store their LSNs anywhere, as
a result a read iterator operating in a read view may erroneously skip
tuples deleted after the read view was created. Let's fix this issue by
storing the LSNs of the left- and right-adjacent chains in each cache
node. The LSN is initialized by the read iterator as the max LSN among
all skipped DELETE statements lying in the chain.

Part of tarantool#11079

NO_DOC=bug fix
NO_CHANGELOG=added later

Each cache chain stores the max LSN among all DELETE statements that are
known to fall in the chain. This LSN is required so that an older read
view can ignore the chain, otherwise it could skip tuples deleted after
the read view was created (see the previous commit).

The problem is, apart from regular DELETE statements, there may be so
called "deferred" ones. Deferred DELETE statements aren't written to
secondary indexes immediately on commit - this is done later, when
the primary index is compacted. If we don't find the corresponding
full tuple in the primary index by a partial tuple key fetched from
a secondary index, we skip it and create a cache chain leaping over
it so that we don't read it again on the next scan. We don't take
into account the deferred DELETE LSN in this case, as a result,
we face the same problem we fixed in the previous commit for regular
DELETEs.

To avoid that, let's keep track of the max LSN among all skipped
statements and use it for the cache chain. Note, we have to patch
vy_point_lookup() so that it can keep a DELETE statement instead of
returning NULL - we need it to extract its LSN for the cache. This
changes the stats a bit hence the vinyl/deferred_delete test update.

Closes tarantool#11079

NO_DOC=bug fix