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've verified that this scenario can indeed occur, but since we evict nodes from cache that have had relationships deleted, it is a transient error-condition.

It would be very nice to resolve though since it requires very defensive coding to work with:

    for (;;)
    {
        try
        {
            for ( Relationship rel : node.getRelationships() )
            {
                doActualWorkWith( rel );
            }
        }
        catch ( NotFoundException e )
        {
            // we hit a relationship that was concurrently deleted, retry!
            continue;
        }
        break; // done retrying...
    }

The fact that `NotFoundException` is thrown from a number of different places makes this even worse, since it might mean that we actually would need to parse the exception message in order to make sure that the exception wasn't caused by a simpler (non-transient) case such as a property not being set...