Let processors and data alterations decide on which indexes they can run

If we would solve this, it would probably be through a new SearchApiProcessorInterface::supportsIndex(SearchApiIndex $index) method which would let processors decide dynamically which indexes they want to support, depending on any criteria they want. (And probably we should then add the same method for data alterations.)

However, I'm not sure this is a good idea for service classes, as those can be changed later. You'd still have to check for the current service class when the processor is called – so maybe you should just do that and include a note to this effect in the processor description. A processor appearing or disappearing when the server is switched might confuse users.

Anyways, the feature request itself is a good idea – most prominently there will probably be several processors and/or data alterations specific to a certain entity type. Giving those an easy way to "hide" themselves for other indexes would certainly be handy.
I'll come up with a patch, shouldn't be more than a couple of lines of code.

Also, as a side note, instead of depending on a specific service class you should depend on a feature, using the supportsFeature() method.

See the attached patch.

Open questions:
- Is supportsIndex() the right/best name?
- Are the doc comments clear and fitting?

It at least works insofar as the bundle filter isn't displayed for, e.g., user indexes anymore.

In the end, "immutable" is just my suggestion. I can't stop people from checking for other things, but then they should do it right (and also check e.g. on hook_search_api_index_update() whether the respective parameter has changed) and I don't take responsibility otherwise. ;)

Great, just committed this.