Issue #3620003: Read the search indexes and the facets of the site into the map

A listing is answered either by an entity query or by a search index, and the difference is not cosmetic: facets, relevance sorting and full-text filtering exist only in the second case. Which one applies to a bundle is a property of the site, and the scanner is the only thing that can find it out.

The map now carries the indexes with the bundles each covers, the fields each holds and whether it is enabled, and the facets a listing can be narrowed by. From the indexes it derives a suggestion of where a listing could be answered from - a suggestion and not a decision, offered only for bundles an enabled index actually covers. Without either module all three sections are absent, and every listing plans as an entity query.

Two things found while writing it, and both are in the code rather than in a comment about it. A facet is not defined against an index: it names a characteristic, an attribute or the category tree of the site's own model, and an index is what makes it cheap to answer. And an index with no server is switched off by search_api itself whatever it was created as, so "enabled" on the map means "something to rely on" - which is why the test sets a server up rather than treating one as scenery.

The bundles a datasource covers are spelled two opposite ways depending on one flag beside the list, so that is asserted against the real module: read backwards it would leave a map that is full and wrong rather than empty and obviously broken.

Closes #3620003