Document responsibility for required extension-provided configuration

Problem/Motivation

Currently extension authors can rely on provided configuration being present in predictable conditions--config/install config is there if the module is installed (and config/optional config is there if dependencies are met. (Assuming, in both cases, that the config has not been subsequently deleted--but at that point many module authors may assume you're basically on your own.)

A number of config entity types support an ::isLocked() method, allowing an extra layer of assurance that a number of modules have used (though with limitations, like 🐛 Do not allow to alter Locked field via UI Needs work ). Also for example a field storage can be set to persist_with_no_fields, preventing deletion, as again some modules have done. Even where these settings aren't available or used, some provided configuration may be effectively required--a module or theme won't perform as expected without it.

But because they disable the default install of extension config to allow recipe authors to select only the specific subset of config they require, recipes change the meaning of default configuration in ways that will have implications for module and theme developers.
A recipe that installs certain modules but doesn't install all their required configuration could lead to breakage. Both config/install and config/optional are affected, though in different ways.

The current spec takes some steps to address this problem:

During install we only install the simple configuration the module provides.

Beyond that, recipe authors can make sure they install any required config. It's up to a recipe to provide a working state for the modules it configures.

Beyond the question of required config, recipes raise some semantic difficulties. "install" no longer really fits, since provided config may or may not be installed. Similarly, "optional" is no longer right, since form modules installed via a recipe all provided config is by default optional.

Finally, as things stand, config in config/optional is installed when its dependencies are met. This means that, even if it's not installed at module install time, it may be installed later, whether or not it's been explicitly added by a recipe.

Steps to reproduce

Proposed resolution

Add documentation.

Remaining tasks

User interface changes

API changes

Data model changes