Changed version to 3.7-SNAPSHOT
MODE-2089 Fixed the child reference iterator in the case of transient insertions.
MODE-2096 Fixed child persistence when transient node reorderings are involved.
The challenge was primarily caused by the fact that a transient, reordered node  was not seen as an appended node, which in effect was loosing the parent-child relationship.
MODE-2096 Reverted a change introduced by previous commit which may impact SNS and cause the inserted & insertedBefore structures to be out-of-sync.
MODE-2092 Restructured and simplified BOMs.
MODE-2105, MODE-2016 Updated Apache Chemistry to 0.10.0 together with CMIS service. Updated the web.xml of both CMIS web application to be secured via the "connect" role.
MODE-2104 Fixed the restoring of nodes when some of them have been moved between versions.
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-2112 Changed the fix for MODE-2104 which did not cover all possible cases.
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-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-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-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.
MODE-2126 Corrected NodeIterator.hasNext() to never advance

Turns out that, in some cases, calling `iterator.hasNext()` multiple times before calling
`iterator.next()` incorrectly advanced the iterator when it should not have. Most cases
were fine, but it was a problem when the following two conditions were met:

1. new children were added to the parent node and these were not yet saved; and
2. the iterator was obtained to find nodes with names that matched a specific
pattern (e.g., `node.getNodes(namePattern)`)

This commit adds several test cases (one of which replicated the problem, while all the
others tests show the problem is limited to the above conditions) and that fixes the problem.
Updated release notes for 3.7.0.Final
MODE-2092 Updated the embedded BOM and added back modeshape-jcr's optional dependencies so that a certain version can be enforced for clients of the BOM. This should make it easier for clients to get the "correct version" of optional components which ModeShape can be configured with in embedded mode.