Allow discovery of configuration UI

Problem/Motivation

Working on the contextual override of configuration objects (in the context of Domains), and I want to build a user interface (UI). I had intended to use Config Translation as a model, but ran into a few issues:

* Config Translation shows us that schema mapping is critical to build a UI for config overrides. Building the form requires the schema.

* Schema has some of the required metadata for building this form. The rest (access control, for instance) is stored in the route.

* Config Translation handles config entities, config objects, and field config. The required metadata for routes and access control (used to build the list of translatable strings) can be derived for config entities and field config, but not for config objects.

* Config objects, therefore, have their own special mappers (*.config_translation.yml), whose sole purpose is to map Routes (and therefore paths and access control) to Schemas, which allows the Config Translation UI to work.

* The support for config objects in those *.config_translation.yml files is limited to string data types, because that's what Config Translation cares about.

Suppose, however, the following use-case for a site:

* When Hungarian is the default language context, timezone should be CEST (UTC + 1:00); when Japanese is the default language context, timezone should be JT (UTC + 9:00).

Right now, you cannot discover the proper data to use to recreate:

* A route to the default configuration form for settings.date.
* The schema used by that form -- though that is potentially addressed in #2095289: Make getEditableConfigNames() public and use it in config_translation.
* Access control rules that should be applied to that form.
* A way to discover config objects that are not strings (like timezone).

Based on my initial research, here's what I found:

* Core works fine if you want to manually edit and load configuration files. The override system handles that cleanly.

* If you want to build a UI for contextual variables, core Config Translation is not sufficient as a model. By design, it only cares about strings, which means it ignores many of the variables that we would want to override per context.

* There are places in core -- specifically entity link registration -- where hardcoded exceptions are made for Config Translation. These instances should, ideally, be identified and abstracted, so that Config extension via context is more general and pluggable. (This is, however, a separate issue.)

Proposed resolution

tl;dr: Add route information to schema definitions for config objects.

After a week of experiments, I see a few options here:

* Don't build a UI for Domain Config or similar modules.

* Ignore the routing system entirely and just create our own forms from schema files -- using https://www.drupal.org/node/1905070 as a guide.

The problem with this approach is that it strips the forms from any context, though we will have form labels. We may also have to maintain a lot of field handling code. In this scenario, the base route would always be admin/domain/domain_config/{setting}. An added problem is that not tying to routing means we may lose proper access control checking, which is why the config translation system uses yml files to make explicit the connection between schema and route.

* Ignore the schema system and try to use Form Alters (as Domain Settings did in D7).

The problem with this approach is that it may prevent us from providing a list of config overrides (which is something that config translation models). It also may suffer from UX problems associated with #2408549: There is no indication on configuration forms if there are overridden values.

* Provide our own version of *.config_translation.ynl files and try to push those into core.

This is what Domain Conf and other modules always had to do, partly because many of the settings had to be vetted for use across contexts. For instance, Logging settings per domain don''t provide much value.

However, doing that in contrib is a losing proposition. Unless you are CTools/Panels/Token/Pathauto, getting modules to commit to the API is a long, uphill struggle, and the support required for users who want, say, different Google Analytics per context, is unworkable.

* Alter schema definitions so that *.config_translation.yml and the like are no longer necessary, and so that other modules can derive UX patterns from existing route / schema definitions.

system.cron:
  type: config_object
  label: 'Cron settings'
  base_route: system.cron_settings
  mapping:
    threshold:
      type: mapping
      label: 'Thresholds'
      mapping:
        requirements_warning:
          type: integer
          label: 'Requirements warning period'
        requirements_error:
          type: integer
          label: 'Requirements error period'

This should work because Config Translation can rewire its discovery system easily to read from *.schema.yml files, and because it has a redundant check for "can this config object be translated" -- it checks both the base_route set by *.config_translation.yml and runs ConfigMapperManager::findTranslatable() on the schema elements looking for valid strings.

This should also work because configuration object forms have (as far as I know) a 1:1 relationship with config objects. Anything with a variable context (like Contact forms) should be using Config Entities, which already fully support auto-discovery.

* Alternately: just add the schema to the default context of the Route:

system.regional_settings:
  path: '/admin/config/regional/settings'
  defaults:
    _form: 'Drupal\system\Form\RegionalForm'
    _title: 'Regional settings'
    _schema: system.date
  requirements:
    _permission: 'administer site configuration'

Remaining tasks

1) Add route definitions to *.schema.yml files for config_objects.
2) Update documentation.
3) Re-wire Config Translation to read from *.schema.yml.
4) Deprecate *.config_translation.yml files.

User interface changes

None.

API changes

* Addition of route element to *.schema.yml
* Deprecation of *.config_translation.yml

Data model changes

* Would force rebuild of Config Translation mapping for existing sites, which is a cache clear.