As a user I want to see what is behind a link to a lexeme in a statement, recent changes, page history and more. I also want to be able to find a lexeme by one of its forms in an entity selector.

Here are examples: https://docs.google.com/document/d/1mqb1b-IkhWySOJ9oArrfOoU8XH6gXKxIRcOFUJQjDME/edit

For the display part we need a way to derive a label and description from the data in a Lexeme. For the search part we need to treat all the forms of a lexeme as aliases.

The derived label would be the lemma.
The derived description would be a combination of lexical category and language of lexeme.
The derived aliases would be all the representations of the forms of the lexeme.

LabelDescriptionLookup should now be interpreted to return display labels and descriptions, not model label and descriptions.

Task breakdown by Daniel

• define service interface for mapping entities to labels, descriptions, and aliases (consider defining separate entities for display and for indexing). The interface can be modeled after LabelDescriptionLookup, but would get an Entity object, not just an EntityId.
• define base implementation for entities that have labels/descriptions/aliases (those that implement LabelsProvider, etc)
• define extension point for alternative mappings for labels, descriptions and aliases for entity types that do not define those directly
• replace direct access to labels, descriptions, aliases and fingerprint in code that should work for all entity types. Code that is specific to an entity type can and should still access labels, descriptions and aliases directly, as structural elements of the data model.

First steps

Define an interface (or interfaces) replacing the usage of LabelsProvider, AliasesProvider and DescriptionsProvider in the following methods:

• LabelsField::getFieldData
• DescriptionsField::getFieldData
• TermSqlIndex::getEntityTerms
• EntityRetrievingTermLookup::getAllLabels
• EntityRetrievingTermLookup::getAllDescriptions

Calls of LabelsProvider::getLabels, DescriptionsProvider::getDescriptions, and AliasesProvider::getAliases should be surveyed so we don't miss anything, but most of these usages are probably not relevant to this ticket.

We then need:

• a default implementation of the new interface(s) that is based on LabelsProvider, DescriptionsProvider and AliasesProvider.
• a way to inject implementations that support alternative mappings and additional entity types.

Note regarding domain boundaries:

This refactoring is an opportunity to improve domain boundaries. The "display" and "search" subdomains are currently not sufficiently separated, as labels (and particularly LabelsProvider) is used in both. Descriptions are only relevant for display (though the display domain is also used in the context of presenting search results). Aliases are only relevant as keywords in the search domain.
Mapping (and mingling) of those domains is currently done by code in LabelField and TermSqlIndex, and more problematically, in the schemas of the data stores updated by that code, namely the wb_terms table and the Elastic index (see LabelsProviderFieldDefinitions and EntitySearchElastic).
The refactoring should lead to the creation of two new interfaces, one for the display subdomain and another for the search subdomain; This does not have to happen immediately though, since it may prove difficult to decide which of the two new interfaces to use in code that currently mixes the two domains.