Integrate with VBO

This should do it.

Some open questions, though:

1. Is this event always sent in the same request as the data is used? If so, we can just use the query object in provideViewData(), make getEntityFromRow() an instance method (i.e., non-static) and with that actually have a chance to apply the relationship we get passed. Otherwise, I don't see any way to incorporate the relationship. (VBO's own implementation actually uses an instance method, but calls it statically, which is obviously a bug.)
2. Is it legal to return NULL from the getter, or do we have to throw an exception? In the Search API, it's of course easily possible to have a non-entity result row, and this is even more true if a relationship is passed (the relationship in question might refer to a completely different datasource than the result row has), so VBO being able to handle this is pretty much a requirement. (VBO's own implementation throws an Exception in some cases, but not sure how it would then react to that.)

Also, I used this opportunity to move SearchApiQuery::getEntityTypes() to the index class. It's useful enough for that, I think.

Also added a change record for the getEntityType() move.

Not sure about the descriptions here. Otherwise this looks great.

Thanks a lot for spotting that! Those were left-overs from when this was in its own module (where it was pretty clear what the event subcriber was doing). Updated the description to be, hopefully, more helpful.

I also think we maybe should rename the eventSubscriber, ViewsBulkOperationsEventSubscriber carries more meaning.

This would violate the (debatable, but at least in this module mostly adhered-to) rule about duplicating the namespace in the class name. Since the namespace is Vbo, I think EventSubscriber is sufficient. We could rename the namespace to ViewsBulkOperations, though, if you think Vbo isn't clear enough. (Though we now also mention the complete module name in the class description.)

Another In principle, however, I must agree that just the bare class name looks a bit "wrong". But it's how we're handling namespaces in the whole module, there are lots of other such examples, where the unqualified class name looks rather unhelpful.

The only other alternative I could think of would be to move it to a different sub-namespace, for non-plugin contrib module integration in general. I.e., something like \Drupal\search_api\Contrib\ViewsBulkOperationsEventSubscriber (or …\VboEventSubscriber). Would you find that better? Having a namespace where there is little chance a second class will ever be added is a bit unsatisfactory anyways.

The event is dispatched on every initialization of VBO views plugin and it happens in 2 places: the view admin form when the VBO field is added / edited and on the actual view where the row selection checkboxes are.

Hm, OK, that's a) pretty logical and b) unfortunate. Without a view object, we unfortunately can't resolve the relationship. (I see how you've solved it in your processor, which makes sense, but unfortunately the Search API stores it's object structure differently.)
However, this sounds like you don't actually need the getter when called from the admin form (which makes sense), so we could maybe just set that one conditionally? That would resolve the problem for us, though it might look a bit funny in the provideViewsData() method. Otherwise, we'd need you to pass the view object to the getter.

I agree that we haven't done this before, but since this is integration with another module I just wanted to make sure that we convey sufficient meaning.
I think that the alternative with \Contrib\ViewsBulkOperationsEventSubscriber in the namespace is a better solution. As that should convey sufficient meaning.

OK, then let's go with that.

I had a feeling I may need to provide the current ViewsExecutable object to the row getter. Included in 8.x-1.x-dev, will soon add it to alpha1 too.

OK, great, thanks! Added code handling relationships. Seems to work well enough, even though it's a bit hack-y. However, the alternatives would have been larger refactoring or copy-pasting of dozens of lines of code.

Please test/review!

Thanks a lot for reviewing!
Graber, do you still want to test and/or review this latest version? Otherwise, I too think we can commit this.

Great to hear, thanks for the feedback!
Committed.
Thanks again, everyone! Great we finally got Search API and VBO working together!