MODE-2090 Add java import statement nodes to the java file and class sequencers.
Also added a mixin that is now being added to the nodes representing java packages.
MODE-2103: Upload binary content outside of transaction.
MODE-2104 Fixed the restoring of nodes when some of them have been moved between versions.
MODE-2100 Updated the processing of predefined workspaces, so that new ones are always added between repository restarts.
MODE-2096 Fixed additional NPE on restore. This was caused by node reorder events trying to retrieve persisted paths for nodes which don't exist.
MODE-2107 Fixed the setting of excluded & included mime-types on the Tika text extractor.
MODE-2112 Changed the fix for MODE-2104 which did not cover all possible cases.
MODE-2113 Updated the messages which indicate which logging library will be used by ModeShape.
MODE-2098 Enhanced the javax.jcr.Property interface which ModeShape's specific getAs() methods.
MODE-2098 Minor JavaDoc improvement/correction.
MODE-2114 Removed redundant code of reference resolving on copy. The code which has been removed wasn't being used because reference resolving occurs earlier in the copy logic.
MODE-2115 Fixed the behavior of copy & clone (across workspaces) for nodes which have auto-created child nodes.
MODE-2118 Changed the GWT Maven plugin usage to use a version property
MODE-2117 Updated session.hasPermission so that when readonly-connectors are present, the method returns false for anything else other than the READ and INDEX_WORKSPACE actions.
MODE-2111 Updated the observation manager to slightly increase the performance of event filtering, making sure that the non-expensive filters are executed first, before the expensive ones.
MODE-2119 Removed the use of partial deltas in clusters.
MODE-2120 Added some checks to prevent duplicate child references from being added/exposed.
MODE-2121 Corrected the concurrency problem within the LazyCachedNode

A new stress test case was added to have lots of calls to the cached nodes, and this highlighted
a problem in the LazyCachedNode.

Although each LazyCachedNode is (mostly) immutable, there still are a number of fields that
are lazily populated. Before this change, these fields were not being updated in an atomic
and thread-safe fashion. Additionally, these fields were not volatile (or Atomic) and thus
there is no guarantee when or in what order one thread sees the fields updated by another
thread.

Most of the fields are self-contained and idempotent, so they did not pose much of a problem.
However, the "parentReferenceToSelf" method used TWO fields to cache the information,
and if a thread saw only one of these fields after being (correctly) updated by another thread,
the reading thread would see an inconsistent state and the logic would incorrectly return null
for the ChildReference containing this node's name and SNS index.

The solution for most of the fields was simply to make them volatile (for most references that
are simply set) or AtomicReference in the one case where the value is somewhat expensive to
compute if it is not really needed.

The solution for the "parentReferenceToSelf" method was to use a single field with an
AtomicReference to an object that encapsulated the information previously stored in two fields.
This also meant that some of the logic could be encapsulated into this new object, and that
a specialized implementation could be used for the root node's ChildReference to itself
(allowing the other implementation to be simplified). The "parentReferenceToSelf" method
is carefully written to not require any synchronization or locking, and thus it is very
fast. Striclty speaking, at any given instant constructing the cached information is idempotent,
meaning that two nearly-concurrent calls might each have to do all of the work. But in
the end, both calls will see consistent information and only one of the representations will
be kept.

After these changes, the stress test runs quite well (albeit with a lot of memory),
and the previously-reported exception is seen no more.
MODE-2122 Added some retry logic in case we're reading the parent's ChildReference objects while it is being modified

Most of the time, this shouldn't be a problem. But the changes make the code tolerant of such rare concurrent modifications
by simply retrying. There is almost no extra cost to doing this.

The stress test added in the previous commit used to periodically demonstrate the concurrent modification exception.
After the changes, the exception no longer occurs.
MODE-2123 Changed the code so that new nodes never try to find themselves in the workspace cache.

Also fixed some resulting regressions for specific situations.