Fix inconsistent counts

Counts were becoming inconsistent when deleting a node and its relationships in the same transaction. This is fixed by inspecting the (pre-state) labels and relationships of the node that is being deleted when building the counts from the transaction state.

Counts also became inconsistent during recovery, since commands in the log did not contain information about the relationship type for deleted relationships. We need this information in order to be able to consistently update the counts, since we cannot trust what is in the store during recovery. This is fixed by adding type information to removed relationship commands in the log.

Recovery of the counts store also has a problem in that the counts store did not have a marking to signal that it is inconsistent, since it was updated in place. To mark the store as inconsistent / incomplete the file is truncated before writing of the store is started.
Reading of a truncated file will show up as an IOException in openVerifiedCountsStore(), this is handled in the same way as the previous internal-consistency-check (which is still in place, and complements this new additional check) of making sure that the number of expected data entries written in the header matches the actual number of data entries in the store.
The truncation is required since we would otherwise not be able to recognize a partial write of the store where the new number of records is the same as the old number of records.