[META] Configuration Language Guardrails

Problem/Motivation

There is a lot of assumption in configuration language handling that is much more rigid than content language handling. This leads to various problems.

1. Global configuration and config entities all have an individual language code that may theoretically be different. These may be a specific human language or a "Not specified" or "Not applicable" or can also be undefined.
2. Most global configuration in core get created without a langcode code. If there are translatable values a language is applied. But this causes problems for configuration entities that do not have translatable elements at installation but may receive translatable elements later, see #3600904: Shipped configuration entities that do not have translatable elements are not set to the site default langcode.
3. Most configuration entities created on the UI get the site default language code. However there are already 4 core configuration entity types that may be selected to be in other languages. And there may be numerous more in contrib and custom code. This already is possible with Language module without any translation on the site whatsoever. This may not be intended by site builders even on multilingual sites and could lead to problems on some sites. See #3608533: Introduce "Configuration language" settings page to control langcode visibility for a solution.
4. When locale module is enabled (but only then), extension shipped configuration is forced to the site default language and translated in-place. When the site default language changes from English to a different language (after locale was enabled) the configuration is not immediately updated but when an extension gets installed it has this dramatic side effect. When the default language is switched from a non-English language to another non-English language, this update does not happen at all but new configuration onwards get created in the new site default language. In short tying configuration base language to site default causes lots of problems. These should be decoupled. See #3337864: Introduce a dedicated "Configuration default language" different from "Site default language".

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet