Optimises the case of severing the `next` link when unlinking a
non-sequential delta in `CollectGarbage`. Consider the case of `TxA`'s
deltas being unlinked, and one of `TxA`'s delta to be downstream from an
inactive non-sequential delta from `TxB`, i.e.:

```
(vertex) ->...->[TxB's delta]->[TxA's delta]->...
```

memgraph#4020 fixed a correctness issue by ensuring that TxB's `next` was
correctly set to `nullptr`, but it did so in a way that required both an
`O(n)` walk up the chain to locate the vertex, and for the vertex's lock
to be acquired. Correct, but regressive from a performance standpoint.

This approach instead just sets `TxB`'s delta's `.next` to `nullptr`
atomically, bypassing the `O(n)` walk and the lock. Doing so is safe
because:
- There can be no concurrent modification of `TxB's` `delta->next`.
Prepends only happen at the chain head, garbage collection is serialized
by `gc_lock_`, and the abort path only operates on active deltas. We
know both the deltas in this operation are inactive because they cannot
escape `waiting_gc_deltas_` unless all downstream contributors are
committed, so we can be the only thing modifying `next`.
- No concurrent reader needs to read anything beyond `TxB`'s delta, as
any deltas that would be needed are protected by the
`oldest_active_start_timestamp` horizon.

Regession discovered by stress test memgraph#4115.