Move KernelTransaction into WriteTransaction.

This is a major change. Previously, KernelTransaction was 1-1 mapped to TransactionImpl, the
JTA transaction in Neo4j. However, this was a flawed design, since the Kernel really is closely
tied to the Neo data source and it's transactions, not the JTA transactions (which are responsible
for handling two-phase commits across neo and lucene).

CHANGES INTRODUCED

With this change, the 1-1 mapping of TransactionImpl is gone, Kernel is now created by the NeoXADataSource,
and for each WriteTransaction that data source produces, an accompanying KernelTransaction is created.
Moving the Kernel into NeoXADataSource allowed making all of the Kernels components final, and removing
all lifecycle hacks in the kernel class.

The PersistenceManager, rather than the TransactionManager, is now responsible for providing access to the current KernelTransaction, just
as it is a bridge to the current WriteTransaction. Since we require "real" transactions for every read now,
the ReadTransaction class has been removed entirely.

It is no longer possible to perform further operations in a read-only transaction that has been marked for roll-back.
Previously, one could have nested transactions that failed, but did not hinder the outer transaction to continue
performing reads. This behavior is no longer allowed, and a few tests have been changed that depended in this behavior.

A few minor changes were introduced as well. The Server had an implementation of the KernelAPI, which has now been made into it's own thing.
It was too soon to make the server use the Kernel directly, better to wait until the kernel is actually ready for prime time.

NEXT STEPS

The relationship between WriteTransaction and KernelTransaction is something that will need further refactoring.
Ideally, the responsibilities of WriteTransaction will move to be performed by subcomponents of KernelTransaction,
and WriteTransaction will go away. The same thing should happen with XAResourceManager - it should not write to
logical log, but should delegate to KernelTransaction to handle all IO.

After that is done, the Kernel will be entirely independent of the JTA code base, and we will be able to run Neo4j
without the JTA layer, with large performance benefits and lowered complexity as a result.

Speaking of performance, every database operation currently passes through PersistenceManager, which does a
synchronized getOrCreate-type call to associate the operation with the current transaction. Since operations
are moving into KernelTransaction, we should be able to slowly remove all methods from PersistenceManager. This
will remove a very large amount of synchronization that is currently being performed.

Once all PersistenceManager methods are removed, it should be possible to merge it with ThreadToStatementContextProvider,
since they will perform the same function.

RISKS

Overall, this is a large change that affects sensitive parts of the code base. However, there is increasingly good code
coverage, with many tests catching our attempts at this refactoring. The end result changes very little in the sensitive
code paths of XAResource and WriteTransaction, and where it does, changes are mostly to increase ease of comprehension.

There is a very important thing to note here, which is that now KernelTransaction is committed along with WriteTransaction,
which means that locks are released as soon as the Neo data source is done with it's work. Previously, locks were held until
the JTA transaction was committed in entirety. This only affects two-phase commits, but we should consider if there are any
ill effects of this with regards to how legacy indexes and neo interact. Do note, however, that it is still possible to
manually grab locks through the Core API, and that those locks will be held until the end of the JTA transaction lifespan.