Add an item type for indexing several types of entities in one index

Here's a patch that would add such an item type, called "Multiple types". A few remarks:

• This datasource suffers from the same problem as the new "bundle" setting: #2520684: Bundle-specific indexes with "Index items immediately" will index other bundles. Which, in this case, means any kind of entity will be indexed if "Index items immediately" is enabled. Less than ideal, of course, so the other patch should definitely be used in conjunction with this one.
• Turns out there is a massive bug in our Views integration regarding non-entity indexes. (Which leads me to believe those are even less popular than I thought.) This patch therefore also contains a fix for that problem, since otherwise testing is significantly harder.
• Due to the problem mentioned in #1184610-32: Limit indexes to specific entity bundles it wouldn't have been possible to filter the list of available fields on the index's "Fields" tab according to the selected entity types. That, of course, would have been even worse than for bundles – if you're just indexing nodes and comments, no-one would expect being able to add user, taxonomy term, etc. fields. (Though, on the other hand, at least the problem with an overlong field list wouldn't apply, as you'd just not add those related fields.)
  Therefore, I decided to go with the "crazy hacks" alternative this time: the datasource now looks at the stack trace to figure out from which index it was called. Sounds insane (and probably is, to a point), but seems to work fine, as far as I can tell.
  However, this makes it all the more important to get this thoroughly tested before committing.

Updated patch – forgot to adjust the index IDs in the new search_api_item_string_id table when they change (due to a feature revert, most likely).

And another revision: the "Bundle filter" data alteration now also supports multi-type indexes (to make up for the bundle setting not being present in the datasource config).

Having the TYPE_SEPARATOR constant might be cleaner, and more analogous to how we do it in D8, but it causes fatal errors when updating completely unnecessarily.
As much as I am a purist, I don't think that's worth it for a module, whose code is in not too good a shape style-wise anyways.

Also: No testers? Would be great to get some feedback from others here, so we make sure to end up with a patch that works for as many people as possible (and doesn't break anyone's site).

Added "Bundle" and "Entity ID" properties and renamed the property machine names to item_id (etc.) instead of _id (etc.).
The former could be handy in some cases, the latter just looks better and also doesn't mess with the Javascript on the "Fields" tab. I initially just used properties starting with an underscore to avoid potential clashes with entity types, but I guess there won't be any entity type with machine name item_id either.

Added an item_label property to the items to get a single field for the entity label (for convenience – would have been easily possible with an "Aggregated fields" data alteration otherwise, except in edge cases).

Committed.