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.
> parsing the document entries and storing them in memory is not done until the first non `getChildReferences` or `getChildCount` call

Sure, that's true. But when do we ever get a `ChildReferences` and do nothing with it? Perhaps we have a few places where we just need to know the total number of children, but I bet it's pretty rare that we do that and nothing else with the parent node in the session. But perhaps considering that the parent may be changing quite often, we do want to postpone creating the delegate. Perhaps if the number of children is small enough, we should create a `Medium` up front??

> The current (pre this commit) code contains a lot of those (I've tried to correct as many as I can find) and they are a  huge performance bottleneck atm.

I completely agree with this. You've fixed all of those, and it's completely independent of any `ChildReference` implementation.