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.
The logic seems right. Basically, we're checking that if the mixin were added to the parent's existing primary type and mixins, then all existing children still have an applicable child node definition and that they don't conflict.

I am going to add several optimizations here (and in a few other places) to do this kind of work only if the mixin has at least one child node definition, or when working with properties only if the mixin has at least one property definition. Seems kind of obvious.