Add unified Links data type for menus, pagers, breadcrumbs...

Problem/Motivation

Many Drupal data structures have similar shapes.

menu.html.twig has:

 * - items: A nested list of menu items. Each menu item contains:
 *   - attributes: HTML attributes for the menu item.
 *   - below: The menu item child items.
 *   - title: The menu link title.
 *   - url: The menu link URL, instance of \Drupal\Core\Url
 *   - localized_options: Menu link localized options.
 *   - is_expanded: TRUE if the link has visible children within the current
 *     menu tree.
 *   - is_collapsed: TRUE if the link has children within the current menu tree
 *     that are not currently visible.
 *   - in_active_trail: TRUE if the link is in the active trail.

links.html.twig has:

* - links: Links to be output.
 *   Each link will have the following elements:
 *   - link: (optional) A render array that returns a link. See
 *     template_preprocess_links() for details how it is generated.
 *   - text: The link text.
 *   - attributes: HTML attributes for the list item element.
 *   - text_attributes: (optional) HTML attributes for the span element if no
 *     'url' was supplied.

breadcrumb.html.twig has:

breadcrumb with:
- url
- text

pager.html.twig has:

 *   items.pages contain the following elements:
 *   - href: URL with appropriate query parameters for the item.
 *   - attributes: A keyed list of HTML attributes for the item.
 *   - text: The visible text used for the item link, such as "‹ Previous"
 *     or "Next ›".

views-mini-pager.html.twig has:

item.previous and items.next with:
- text
- href
- attributes

Those data structures are not only different, they are also sometimes loosely defined and hard to process.

We need a consistent way of interacting with such data:

• for templating & rendering: use a template made for links (example: language selector) for a menu, use a template made for pager with mini pager, display a menu as tabs... without risky conversions. Also, with the raising popularity of SDC components, front-devs don't always know in advance how their template will be used in Drupal app, and such a common format can be used in component props
• data alteration: mechanisms altering links (add SEO tags, check allowed URL domains, mark external links, apply display context and access restrictions...) can be unified

Proposed resolution

We may need a new data type implementing ListInterface for the links and ComplexDataInterface for each link.

In UI Patterns 2 project, we tried to achieve such a unified data structure: LinksPropType, based on menu.html.twig because it is more complete, with a normalization mechanism to be compatible with other data structures (links, pager, breadcrumb...). It may be a good start to add such data type in Core.

We can also take into consideration Link field type because field API is built upon Typed Data API.

User interface changes

No

API changes

No new API, the data type is using existing interfaces.

Data model changes

Yes. It will depend of the strategy:

• do we break compatibility by replacing all the data structure listed in the examples above?
• do we keep existing data structure but redefine them as variation/overrides of the new data type?