Config entities' dependencies can be validated

As part of a larger effort to make config entities validatable at the data layer, config entities now have the following validation constraints:

• config dependencies must be the name of an existing piece of config
• module dependencies must be the machine name of a currently installed module
• theme dependencies must be the machine name of a currently installed theme
• Config entities can only have the following types of dependencies: config, content, module, theme, and enforced. Any other type of dependency will raise a validation error.

These rules apply to enforced dependencies as well.

⚠️ To be clear, this validation is not actually used yet in Drupal core. These changes will take effect as more and more config entities are converted to do validation at the data layer, rather than via the form system.

Additionally, FieldConfig entities must list at least one field storage config in their config dependencies, and Editor entities must list at least one filter format in theirs.

The following generic validation constraints were added:

• ConfigExists: Validates that the input value is the name of a piece of existing config.
• ExtensionName: Validates that the input value is a valid extension name (that is, matches the correct format -- it does not need to be the name of an actual installed extension).
• ExtensionExists: Validates that the input value is the name of an installed extension. This constraint requires one option, which is the extension type (either module or theme).
• RequiredConfigDependencies: Applies only to config entities. Validates that the entity's config dependencies include entities of the specified type(s). The required entity type IDs are passed as an option.
• ValidKeys: Validates that an associative array (or "mapping") only contains a particular set of allowed keys. The set of allowed keys may be passed as an option, or you can provide the string <infer> to automatically determine the allowed keys from config schema.