[META] Provide entity integration with Views

We need to support the new Property API properly, make sure it's easy for modules implementing entity types to integrate with views, make sure translations and revisions work.
This will also decrease the work needed by other entity-supporting backends (Search API, EFQ) since they would get the properties for display with little extra work. (and they can choose what they want to do on the filter / sort side, since Search API for example only filters / sorts fields in the index)

Background: 7.x-3.x

The support for entities in 7.x-3.x is bolted-on and slightly awkward, thanks to the almost-nonexistent Entity API in Drupal core, and the long evolution of the entities since the D7 port of Views started / got its first release.

We have:
- Field API integration, providing fields for each entity type, automatically.
- Each base table of an entity type declares its entity type.
Example: $data['node']['table']['entity type'] = 'node';
This is used by:
- A query object method get_result_entities() that loads all entities from the given relationship, but doesn't support revisions.
The Field API handler doesn't use get_result_entities(), opting for its own code instead, that does support revisions.
- A field handler called views_handler_field_entity used as a base for field handlers that use the entity values, instead of the values fetched from the query.
This is really awkward since you get a new base handler, but don't get entity-generic per-property handlers (string, numeric, prerender_list etc) which decreases its usefulness.
- A way to define "query plugin agnostic" fields by adding the definition to $data["views_entity_{$entity_type}"]. This is used by the node links, for example.
Since they are added to $data['views_entity_node'] instead of $data['node'], they appear on views that display nodes fetched by the Search API or EFQ query plugins as well. These generic fields usually use a handler extending the views_handler_field_entity field handler.
- All field handlers have get_value() / sanitize_value() methods used to fetch / sanitize values used by the render methods. This allows an inheriting handler to change how the value is fetched (taking it from the loaded entity instead of taking it from the row fetched from the database, for example) and allowed efq_views to provide relatively slim handlers that replace the current sql-specific ones shipped with views.
- Entity API provides the Metadata API (property info) and a set of generic field handlers for each property type (so, for example entity_views_handler_field_numeric extends views_handler_field_numeric and overrides get_value() so that the property is fetched from the loaded entity).

Drupal 8 core changes:

#1498634: [meta] Define revision/translation SQL schema for core entities (no patch) resulted in these two changes in Drupal core:
http://drupal.org/node/1722906
http://drupal.org/node/1790138

So, we now have three tables for each entity type:
- {entity} (entity_id | uuid | revision_id | bundle_name | langcode)
- {entity_property_data} ( entity_id | revision_id | langcode | default_langcode | label and all other properties)
- {entity_property_revision} (entity_id | revision_id | langcode | default_langcode | label and all other properties)

So for nodes, that's {node}, {node_property_data} and {node_property_revision}.

We are also getting a Property API that's almost ready:
#1696640: Implement API to unify entity properties and fields

These changes mean that from now on we'll need to use the full entities to display the properties (the accessor methods on the entity select the correct language and possibly do language fallback).
This means that no field handler for any entity type needs anything from the query anymore in order to display the value, we use the entity for both property and field display. This also means that theoretically they could work across query plugins.
Of course, we still need to handle the schema aspect correctly because of filters and sorts.

This also affects Search API, because it basically means that fields in the index can be queried on, but they can't be displayed (which sucks a bit, because I see Search API as a great denormalization tool)

Work done in 8.x-3.x so far:

#1758634: The query plugin should load entities after the query has been executed

Summary:
- Removed get_result_entities() from the query object. Added a load_entities() method (used by the query execute(), not the handlers!) that also supports revisions (like the Field API code, unlike the old get_result_entities()). Entities are stored either in $row->_entity or $row->_relationship_entities[$relationship_id].
- Made the base fields of all entity tables always added to the query (so that we can actually load the entities), and because of that, removed "pure distinct".
- Removed Field API post_execute() and half of the query() code.
- Removed the "Entity" field handler since now all handlers have access to the entities matching the row.
- Added a convenience get_entity() method to the base field handler (FieldHandlerBase) so that each handler can easily fetch its entity.

The new entity loading code in load_entities() supports revisions and that's something that can be backported to the 7.x-3.x get_result_entities method.

Future expectations

- Properties of an entity type are automatically made available (just like Field API fields). This includes both displaying, and filtering / sorting (we have a key in property info telling us if the property exists in the schema).
- Since we're already making properties and fields available, we might as well provide automatic integration for entity types.
This means that if you declared an entity type and its properties to Drupal, there's no need to do explicit Views integration.

Implementation

Drupal 8 no longer contains an "entity" module, so the implementation needs to happen in the "system" module integration.

- We declare each entity type, and all properties (just like we do for fields, allowing the list to be altered in the process) in system_views_data().
The property info is mapped to views data in a helper function that can be used by other query plugin providing modules (like efq_views) to add the properties to their own base tables.
- We provide a hook_views_entity_property_info() (name not even remotely final) that allows you to specify your own query-plugin-agnostic properties, such as "edit link", or whatever gets left out of the core property list.
(Do we want to tell users to just alter the core property list instead?)

Click sorting

We might want to figure out an alternative implementation for click sorting, feels a bit odd to do it through the field handler, which suddenly ties it to the schema and SQL.

Aggregation

If we're using the full entity for properties as well, does aggregation (the SQL-specific way it works right now) even make sense for entities?

Problems:
- The entity determined for a row might be completely wrong
Example: node view, shows number of nodes per uid, so bojanz | 10, dawehner | 30, etc
In this case, there's no valid node entity to load. We take the MIN(nid) and load the first one, which still isn't right.
- We're assembling fake entities, which can cause the system to choke, and which won't work with translations
That's what the Field API handler does right now. So if fetched a COUNT(uid) instead of uid, that's going to be stored as the uid, which is wrong (confuses the system). Also, since we're assembling the entity ourselves, some languages might be missing, leading to translations failing (or fallback) failing.
The solution might be to always use the actual loaded entity instead of assembling the fake entity, but that would kill the usefulness of aggregation to a smaller or larger extent.
- It makes the code look odd.
So, imagine a views_handler_property_string extends views_handler_strings (using the old handler naming convention for clarity). That handler overrides get_value() to get the value from the entity, and overrides the query() method to do nothing.
Now, to support aggregation we need to check for it, and then fallback to the parent methods.

Revisions

In Drupal 8 we finally have the same properties available for the current and past revisions. So declaring the revision table, and the properties there (for the second time) is not actually needed, we could switch between the current and revision table based on an "Age" setting in the Views UI ("Show current revision" VS "Show all revisions").
This is non-critical and can be done in a followup, just wanted to note it down.