[meta] Integrate with UI Patterns module

Problem/Motivation

The UI Patterns module integrates patterns with Drupal entities and admin UI. From the module's description:

Define and expose self-contained UI patterns as Drupal plugins and use them seamlessly as drop-in templates for panels, field groups, views, Display Suite field templates, paragraphs, nodes or any other entity types.

Integrating with UI Patterns would allow the use of components anywhere patterns are currently supported.

Parallel/related issues on UI Patterns:

• Advanced field type schema
• Integration with Component Schema?

Proposed resolution

The aim in this meta issue is to map out a potential approach. From there, we can open child issues.

Work directly in Component Schema

• Allow consuming modules to determine the type of component variable. See this comment by @donquijote for rationale and discussion. We could consider doing so by adding a key to variable schema definitions, such as ui_variable_type. Values might include 'setting' for a setting-type variable, 'field' for a field-type variable, and 'content' for arbitrary content (see #3175289: Provide a standard way of handling arbitrary content). It would be preferable however if we were able to define this at the variable type level rather than per-variable. For example, component_string and component_boolean where either provides_class or provides_attribute is TRUE would be of type "setting".
• Add libraries support, using a format identical to that in UI Patterns. Extend the process_component() Twig extension function to add a component's libraries.

Work in a submodule, perhaps component_schema_ui_patterns

• Declare dependencies on both ui_patterns:ui_patterns and ui_patterns_settings:ui_patterns_settings.
• Include a UiPatterns/Pattern plugin type that uses a deriver. This will be similar to the deriver in UI Patterns Pattern Lab.
• Add a UI Pattern per component or for a subset of the components. TBD, do we need a key in the component definition to determine if it's appropriate for a pattern? In the deriver:
  • Use the component machine name key as the pattern machine name key. TBD: what validation do we need to do?
  • Add a field for each field-type variable.
  • Add a setting for each setting-type variable.
  • When iterating variables of type sequence or component_sequence, rather than appending more fields or settings, instead derive a child pattern, designating the parent (parent_pattern or similar).
  • TBD: how to handle variables of the following types: mapping, component_mapping, component_template, component_component (nested component)?
  • Copy over properties that are directly parallel between components and patterns: label, description, libraries.
  • Copy over the component component_template value as the pattern use value; see relevant documentation.
  • TBD: do we want to support variants? If so, how?

TBD: given the parent-child relationship of component-derived patterns, how do we ensure the child patterns are available only in appropriate contexts? For example: If a parent pattern has been selected for a view mode or layout, do we then offer field formatters using child patterns?

Remaining tasks

User interface changes

API changes

Data model changes