Respect the "no_ui" definition key for plugins

Thanks for starting on this!

1. +++ b/src/Form/IndexProcessorsForm.php
   @@ -359,6 +359,9 @@ class IndexProcessorsForm extends EntityForm {
   +        if (!isset($processor_definition['no_ui']) || $processor_definition['no_ui'] === FALSE) {
   +          continue;
   +        }
   

   The logic here seems inverted, it should just be !empty($processor_definition['no_ui']).

2. +++ b/tests/src/Functional/ProcessorIntegrationTest.php
   @@ -305,6 +306,14 @@ class ProcessorIntegrationTest extends SearchApiBrowserTestBase {
   +  public function testNoUiPlugins() {
   +    $this->loadProcessorsTab();
   +    $this->assertSession()->pageTextNotContains('No UI processor');
   +  }
   

   I think we can instead just make this another check*Integration() method. We can even assert there that enabling the processor programmatically still works.

Also, I guess specifically for processor, we simply need to adapt \Drupal\search_api\Processor\ProcessorPluginBase::isHidden(). Doesn't work for any of the others, but still …
(Also, contrary to the IS, I think we don't have any UI for search displays. Facets or other modules will have to take care of those.)

Maybe we should just move isHidden() to our ConfigurablePluginInterface base interface (or even make an additional parent interface for that, to also catch data types and displays) to make this easier? Looking for a particular plugin definition key isn't exactly good DX.

Anyways, I see no particular rush for fixing this issue, as it isn't really causing any problems. If we actually want to deprecate a plugin, or someone wants to use the no_ui key for their own plugin for some reason, we can still work on it then.

How about this? (Maximum suggested variant from #5, including a common interface and base class for all our plugin types. (It does add another method to all the plugin interfaces (except processors), but should be fine BC-wise since they all come with a plugin base class.))

To be a bit nicer regarding BC, I also refrained from changing the getInstancesOptions() methods (for data types and parse modes). Not sure what people expect to get there, so better to keep it as-is.

Ah, damn.

Hm, I can’t reproduce the problem normally in the UI. Anyways, I did spot one mistake, maybe this caused the test fails? (Tests run fine now locally.)

Excellent, thanks for reviewing!
Committed.