Delays node/rel record changes until commit time

This completes the move from changing record state at the point of making
that change in the transaction to the point where the transaction is
committed. A side effect of that is that KernelStatement no longer needs
access to TransactionRecordState and so the abstractions gets clearer.

The issue provoking this change was that a transaction could create a
relationship and delete it in the same transaction, with the outcome that
a command was created saying to delete that relationship, even though it
didn't exist before the transaction started. Then if replaying a log
containing such a transaction there would be and exception thrown applying
that transsction where the id of that record couldn't be freed since it
was above highId.

This commit also removes duplicate and unexpected checks for if records
exists at the point of converting transaction state into record state. All
those checks now exist in the KernelAPI, and so they were removed from
TransactionRecordState.
Merge pull request #2969 from tinwelint/2.2-alter-entity-record-state-at-commit

Delays node/rel record changes until commit time
Store application ordering of transactions w/ legacy index changes

Only a single transaction at a time can append to the log buffer, but
multiple transactions can apply changes onto the store simultaneously in
2.2. For graph and schema indexing changes there are the high level
entity locks that guarantee correct ordering of transactions wanting to
change the same records. However for legacy indexes there are no such
ordering. This might result in for example an REMOVE+ADD turning into a
ADD+REMOVE, i.e. two different end results.

So, this commit introduces ordering of transactions making any legacy
index changes so that such transactions gets applied in the same order
as they were appended to the log. Transactions that doesn't change
any legacy indexes will not be ordered like this and will pay no cost
whatsoever for the ordering introduces here.

This commit also adds apply() to NeoCommandHandler such that
CommandApplierFacade can call a round of apply() to all appliers and the
another round of close(). This fixes an issue where store application
locks would be released too soon.
Previously:
  * apply graph changes
  * release graph update locks
  * apply schema index changes
  * apply legacy index changes

Now:
  * apply graph changes
  * apply schema index changes
  * apply legacy index changes
  * release graph update locks