MODE-2271 Implemented a pseudo-lazy Medium child references

This pull request creates and uses (always) a new `LazyMedium` child references instance, which wraps the `Document` children array and lazily loads & caches everything into a `Medium` instance to which all `ChildReferences` calls are delegated. In other words, the approach is "pseudo-lazy" because at some point all the child references are parsed & stored. However, with this approach repeatedly calling `parent.getChildReferences()` wouldn't incur any performance penalty.

In working on this, I profiled & tested 2 different approaches:
+ never cache the child references - i.e. always traverse the document (array) and perform whatever logic is required (e.g. get child by key)
+ cache the child references into a `Medium` instance and always delegate to that

Performance wise, coupled with the fact that `Medium` was updated & simplified to pre-compute all SNS indexes, (2) is vastly superior to (1) - by about 6 - 10 orders of magnitude whenever we're dealing with 5000 or more children under a parent. Therefore, the proposed approach is to always use 2, since IMO it's as fast as we're going to get with the current structure (`Array`) of storing children. 

Some perf tests were updated/created and used during the work and all of them are located in the `modeshape-performance` package.  With this PR, using a `LevelDB` cachestore, the performance of inserting 100k nodes (SNS) each with 10 properties and then subsequently reading/inserting baches of 1000 SNS is:

```
(writing) Inserted 100000 nodes in: 1 sample: min=00:02:50.731,416; avg=00:02:50.731,416; median=00:02:50.731,416; stddev=0.0; max=00:02:50.731,416
(reading) min=00:00:00.337,595; avg=00:00:01.647,447; median=00:00:00.694,181; stddev=1.6068739749824874E9; max=00:00:03.910,565
```
This PR also contains another commit which fixes the potential corruption of the `CHILDREN` array in the parent document, corruption which would easily occur when children were reordered. However, the "hack" for https://issues.jboss.org/browse/MODE-2120 was hiding the issue very well.
Ok, I'm going to get picky here. Since you're returning from the `if` block, there is no need for an `else` block. So why not just do this?

            if (context != null && context.changes() != null) {
                //we only want the context-sensitive behavior if there are changes. Otherwise we've already precomputed the SNS index
                return super.iterator(name, context);
            }
            return iterator(name);