MODE-1745 MODE-1739 Changed how Delta impls are created

Recent changes changed the way Delta implementations are created.
In particular, the SchematicEntryWholeDelta instances were created
with a clone of the document. Since subsequent changes were made
to the original document, the SchematicEntryWholeDelta didn't include
these subsequent changes and they were lost, causing various exceptions.

Also changed some of the trace logging messages on both Delta
implementations to be more useful.

I'm able to not only successfully run a full integration build,
but I'm able to successfully run the test cases for both MODE-1745
and MODE-1739 using Infinispan 5.1.2.FINAL or 5.1.8.Final.
Occassionally when running the MODE-1739 tests I do get one or two
NodeNotFoundInParentException (see MODE-1739 for details) early
on in the test (unable to find a path of an existing node when
checking permissions), but it simply fails that request and continues.
This error often happens almost immedidately in the test and is
rarely repeated more than once.

Note that in addition to this problem, the tests are not able to use
Infinispan 5.2 -- that's because we're using the SchematicEntryDelta
(a diff-based impl), and we haven't yet fixed the problem there.
MODE-1745 Added repository-level locking to prevent concurrent initialization

There were cases when two processes in a cluster would each attempt to
initialize the system content, and obviously one of them would fail.

This code introduces two new fields to the single 'repository:info'
document that represents the metadata about the document. There can
be only one of these in the whole repository. One of the new fields
is 'intializer' and represents the random UUID of the process that
is performing the initialization of the repository. Each process
first looks for this document, and if it doesn't exist the process
creates a new document with the various metadata fields (including
the new 'initializer' field) and attempts to 'putIfAbsent'. It then
looks up the existing document in the store; if the 'initializer'
field matches its own, then it continues to initialize the repository
with the system content (e.g., node types, namespaces, etc.),
initial content, etc. If the document's 'initializer' value does not
match the current process, then another process is performing the
initialization and this process should wait until initialization is
complete. The latter is signified by the other new field, called
'initializedAt', which is the timestamp that the initializing process
completed the initialization. Non-initializing processes simply
block for up to 10 minutes, re-fetching the 'repository:info' document
and looking for the 'initializedAt' field. As soon as this field is
found, the non-initializing processes continue.

All of this logic is in the RepositoryCache class. The JcrRepository's
RunningState.postInitialize() method is what calls the RepositoryCache's
completeInitialization() method (which uses a transaction to ensure
the 'intializedAt' field is set atomically).

Note that any process that joins the cluster after the 'repository:info'
document has been updated with an 'initializedAt' field will immediately
proceed with starting up (since the repository initialization had
already been completed).

Also, all processes still attempts to register the node types defined
within the repository's configuration file. This is obviously redundant
when each process's configuration file contains the same node types.
However, this provides a convenient way to register new/updated node
types by simply starting up another process with an updated list of
CNDs.

Integration builds pass with these changes, and the test cases
in MODE-1745 and MODE-1739 run successfully when using these changes
and Infinispan 5.1.x. There are still issues when run with
Infinispan 5.2 due to the diff-based delta usage (see MODE-1745
for details).