MODE-2276 Changed how child node definitions are found when adding a child

The new logic attempts to limit the need to find the number of existing children with the same name as the proposed child, and it provides reusable components that will improve efficiency when using a single session to adding lots of children under the same parent. It also uses a more efficient algorithm if the parent's primary type and mixin types combined have just one child node definition; this is the case in lots of situations, including when adding children to `nt:unstructured`, `nt:folder`, and `nt:file`.

I also ran two separate performance tests, both in `org.modeshape.test.performance.InMemoryPerformanceTest`

* `shouldAllowCreatingManyUnstructuredNodesWithSameNameSiblings()` - Adds 10k nodes in a single save, then repeats that a total of 12x, with some noticeable improvement. The time for each of the 12 batches:
  * **before**: 12 samples: min=00:00:01.755,942; avg=00:00:**04.303**,606; median=00:00:04.805,989; stddev=1.0220770084115483E9; max=00:00:05.116,627
  * **after**: 12 samples: min=00:00:01.764,728; avg=00:00:**03.856**,074; median=00:00:04.705,386; stddev=1.3948315738242652E9; max=00:00:05.218,119 (_about 10% faster_)
* `shouldGetNodePathsInFlatLargeHierarchyWithSns()` - Insert 100k nodes with 10 props each under the same parent in batches of 500. Total time to insert 100k nodes:
  * **before**: **01:16.143**
  * **after**: **00:22.925** (_3x faster!_)

Each of the tests was run multiple times in each configuration, and the results shown above are quite representative of the results of other tests in the same configuration.
I think we should add an annotation whether this is expected or not to be thread safe. The current implementations (the different types of `SiblingsCounter`) are threadsafe, although it's not really a requirement since they are only used as local variables in various places.

I'm saying this because when I worked on the `ChildReferences`, there was no explicit documentation on the parent interface regarding the expectancy of multi-threaded behavior. It was all made "clear" when running `ConcurrentWriteTests` :smile: