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.
I'm curious why this is now done in a separate loop.