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.
Merge pull request #3501 from davidegrohmann/2.2-counts-consistency

Fix inconsistent counts
Introducing GraphDatabaseService.execute(...)

Enables executing cypher queries without having to keep track of an
ExecutionEngine instance, instead the database keeps the ExecutionEngine
internally.