MODE-1746 Added test case to replicate deadlock scenario

Added a test method to the ConcurrentWriteTest that replicates how separate threads can deadlock while attempting to update several nodes.
MODE-1746 Use explicit locks to prevent deadlocks

Added quite a few debug and trace logging calls to help investigate transaction-related operations.

Added explicit locking to prevent deadlocks. Locks for all modified nodes are now requested at the beginning of the transaction (rather than incrementally as needed to apply the changes in the same order as modified by the session). The locks will either all be acquired or none of them will be acquired, allowing the "save()" operation to retry to acquire the locks one additional time. If the locks still cannot be acquired (or if Infinispan throws a TimeoutException because the locks could not be acquired after the configured period of time), ModeShape will rollback the transaction.

The WritableSessionCache will attempts to retry the transaction if and only if the save() operation started the transaction. If there was already an existing transaction, ModeShape cannot restart it and therefore it must fail.

In all cases, should locks not be acquired during the "Session.save()" call, an org.modeshape.jcr.TimeoutException will be thrown. Client applications can catch this and simply retry calling "Session.save()" again as many times as desired.

Under configurations that experience a high amount of concurrent operations on the same set of nodes, the Infinispan configuration should probably use deadlock detection.
MODE-1746 Minor changes to previous modifications

Several small changes to the previous commit were suggested by Horia,
and implemented with this commit.
MODE-1745 Corrections to Schematic's state transfer

Several issues related to state-transfer were identified and corrected within Schematic's DeltaAware implementation. These primarily dealt with using diff-based deltas when using Infinispan 5.2.0 (tested with Beta6 and later), the implementations of the two deltas (and related classes), and how merges are made, and removal of the NullDelta class.

With these changes, the test projects in MODE-1745 and MODE-1746 work better. There still are problems with state transfer during repository initialization. See MODE-1745 for details.
MODE-1729 Removed newlines in element values in arquillian.xml

Not sure why the newlines matter, but they're okay on Windows but
break the build on OS X.
MODE-1741 - Updated Git connector so that only tree/master content is indexable.
MODE-1741 - Updated the Git connector so that indexable branches are configurable
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).
MODE-1745 Minor changes and additional debug statements
MODE-1745 Removed code that was commented out
MODE-1745 Corrected the names of the child references, which was recently changed (incorrectly)
Merge branch 'mode-1746' of git://github.com/rhauch/modeshape into rhauch-mode-1746
MODE-295: Add apache chemistry version
MODE-295: Add apache chemistry to dependency management
MODE-295: Base CMIS library
MODE-295: Base CMIS library
MODE-295: Base CMIS library
MODE-295: AS7 integration
MODE-295: Add cmis dependecy to distribution/pom.xml