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.
no, because that context is always wrapped whenever there are changes coming from the outside.
So a `WithChange` would wrap "that" context and without doing an "instanceOf" there is no way to get this correctly to work (i.e. WithChange requires BasicContext).
The solution was to change the code in `Medium` to be "smart" enough and check if there are/aren't changes in the context.