Index indexed children rather than scanning per element

[tommyk-gears]

IndexedElementsBinder discovers which indices exist beneath a name by scanning every
property name in the source:

for (ConfigurationPropertyName name : source.filter(root::isAncestorOf)) {
    ConfigurationPropertyName choppedName = name.chop(root.getNumberOfElements() + 1);
    if (choppedName.isLastElementIndexed()) { ... }
}

The indexed property-name syntax carries no length, so the only evidence that tags[0]
exists is that some name happens to look like tags[0].name. That means one full scan per
indexed element. When many indexed elements share a namespace — a large Map whose values
contain lists, say — binding becomes quadratic in the number of elements.

Binding a Map whose values each contain two lists:

entries	before	after
100	22.7ms	12.7ms
400	130.9ms	21.3ms
800	456.5ms	30.1ms
1600	1879ms	59ms

The per-element cost stops growing with the size of the source.

Changes

Add getChildrenOf to IterableConfigurationPropertySource. The default implementation
performs the same scan as before, so sources that cannot answer more cheaply are unaffected.
SpringIterableConfigurationPropertySource overrides it and answers from mappings built
during the pass its cache already makes over property names.

Answer containsDescendantOf from those mappings. The cache built a separate descendants
set purely so containsDescendantOf could avoid scanning. The children mappings have the
same key set, so that set is now redundant and is removed along with addParents and its
capture flag.

Like addParents before it, addChildren stops walking as soon as it reaches a parent that
is already known — whichever name first recorded that parent walked the rest of the way up.
Without that short-circuit the mappings take roughly twice as long to build. With it,
building the mappings for 6000 property names takes 3.6-4.2ms, against 3.6-4.1ms for the
descendants set they replace.

The ancestorOfCheck guard is kept in containsDescendantOf, since a mapper with a custom
check (SystemEnvironmentPropertyMapper) still needs its own ancestor logic. The children
mappings themselves are built for every source, because getChildrenOf needs them
regardless of which mapper is in use.

Notes

• getChildrenOf has one caller today. I looked at the other isAncestorOf/isParentOf
  sites (NoUnboundElementsBindHandler, ValidationBindHandler,
  assertNoUnboundChildren); they all want descendants rather than direct children, so
  none migrate cleanly.
• Memory use of the children mappings is not measured. They hold a Set per parent where
  the descendants set held one flat set of parents.
• Tests cover direct children, agreement with the default implementation, equivalent names
  written differently (foo-bar / fooBar), and system environment sources.