Add support for node-level caches

Caches are currently configured only at the level of individual cores, sized according to expected usage patterns for the core.

The main tradeoff in cache sizing is heap space, which is of course limited at the JVM/node level. Thus there is a conflict between sizing cache to per-core use patterns vs. sizing cache to enforce limits on overall heap usage.

This issue proposes some minor changes to facilitate the introduction of node-level caches:

1. support a <caches/> node in solr.xml, to parse named cache configs, for caches to be instantiated/accessible at the level of CoreContainer. The syntax of this config node would be identical to the syntax of the "user caches" config in solrconfig.xml.
2. provide a hook in searcher warming to initialize core-level caches with the initial associated searcher. (analogous to warm(), but for the initial searcher – see SOLR-16017, which fwiw was initially opened to support a different use case that requires identical functionality).

Part of the appeal of this approach is that the above (minimal) changes are the only changes required to enable pluggable node-level cache implementations – i.e. no further API changes are necessary, and no behavioral changes are introduced for existing code.

Note: I anticipate that the functionality enabled by nodel-level caches will mainly be useful for enforcing global resource limits – it is not primarily expected to be used for sharing entries across different cores/searchers (although such use would be possible).

Initial use cases envisioned:

1. "thin" core-level caches (filterCache, queryResultCache, etc.) backed by "node-level" caches.
2. dynamic (i.e. not static-"firstSeacher") warming of OrdinalMaps, by placing OrdinalMaps in an actual cache with, e.g., a time-based expiration policy.

This functionality would be particularly useful for cases with many cores per node, and even more so in cases with uneven core usage patterns. But having the ability to configure resource limits at a level that directly corresponds to the available resources (i.e., node-level) would be generally useful for all cases.