Lock-free loading of relationships

Removes node lock previously used during loading of relationships. This
lock would contend with committing transaction and produce latency issues.
The lock prevented cache poisoning issues introduced by race conditions
between committer and reader(s).

To achieve a lock-free solution some guards had to be added for various
corner cases. These are:
- Committers are now aware of ot he fact that, and parries for,
  concurrent readers loading and caching relationships committed by the
  committer, before the committer has put them into cache itself,
  producing duplicates when the committer would add them.
  (Issue comes from the fact that store is updated before cache).
- Committers uses knowledge about how relationships are stored on disk to
  be able to tell if any reader has loaded the relationships it has just
  written to the store, before updating the cache. This logic sits in a
  filter which is consulted before adding relationships to the cache.
- Nodes evicted from cache as part of being upgraded from sparse to dense
  now happens as part of updating the node instead of as a separate step
  during commit. This to also guard for concurrent readers.
- Simplification and reduction of code and logic of DenseNodeChainPosition
  where all individual chain positions are initialized eagerly, so that
  the filtering logic (as mentioned above) becomes simpler.
- Ordering of relationship-related records when applying transaction
  to store changed to: relationships, relationship groups, nodes so that
  additions to relationship chains are seen atomically by
  concurrent readers.
I wonder if there is a window of opportunity where this can miss some positions in a chain.

Imagine multiple relationships (of the same node) being removed in the same transaction. This method will be removed for each of them. Say relationships `a` and `b` are being removed in this transaction, and that the update to `a` comes before `b` in the transaction command application order, but that `b` comes before `a` in the relationship chain order. Imagine also that the position is `b`. Now when the transaction is applied we will first invoke this method to check if the position is `a`, it is not, so no update takes place. Then along comes a reader, and reads relationships, advancing the position so that it is now `a`. As we progress through updating the transaction we will eventually arrive at `b` and check if the position of this node is `b`, since it is now `a` we will not update anything. The application of the transaction ends without updating this node. Now the reader comes back and asks for more relationships, the next position it will read is `a`, but this record has been deleted... **Kaboom!**

Quite possible this scenario can be simplified, `b` might not have to be part of the transaction. I believe we handle it being part of the transaction already by removing deleted relationships from the cached state of the node *after* we've updated the positions, is that correct? More importantly though, do we have anything in place for making sure that we don't miss updating positions like this because they were not the current position when we checked, but the reader advanced to that position later and concurrently.