[meta] Allow config types to opt in to config validation, use "FullyValidatable" constraint at root as signal to opt in to "keys/values are required by default"

Problem/Motivation

1. #3361534: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate introduced strict config schema checking that includes checking validation constraints.
2. #3379899: Follow-up for #3361534: config validation errors in contrib modules should cause deprecation notices, not test failures softened this for non-core modules (contrib + custom): it converts validation errors to deprecation notices.

But @alexpott, @bircher, @borisson_ and I agreed at DrupalCon Lille that this is still too disruptive while discussing #3364108: Configuration schema & required keys. And @effulgentsia has expressed similar concerns privately over #3364109: Configuration schema & required values: add test coverage for `nullable: true` validation support.→ Removed from the scope of this issue since #10, the removal of deprecation notices for contrib modules was moved to #3402168: Follow-up for #3361534: Config validation errors can still occur for contrib modules, disrupting contrib, which already landed since 👍

There is a dual problem to be solved here, that SHOULD be solved using one mechanism/signal:

1. Enabling contrib/custom modules to signal when a config schema type is considered fully validatable, and hence they'd want \Drupal\Core\Config\Schema\SchemaCheckTrait::checkConfigSchema() to cause test failures whenever that is violated.
2. Enabling Drupal core to know when a simple config object or a config entity type is considered fully validatable, which is necessary for #2300677: [PP-2] POST/PATCH config entities via REST for config entity types that support validation.

Steps to reproduce

N/A

Proposed resolution

Allow non-core modules to opt in to strict config schema checking. Somehow.

Proposal 1: type: strict

1. each type (a top-level key in a *.schema.yml file) can specify strict: true, and nothing else can
2. for a given node in a config object's node tree, we only run validation constraints if its type has strict: true
3. a config object (simple config or config entity) is only fully validatable if all of the config types present inside it (directly or indirectly), have strict: true
4. Later, for example in Drupal 11 or 12, we could then choose to start triggering a deprecation error for non-strict types corresponding to simple config & config entities, to inform that this will become required in Drupal 12 or 13. This would lead to far fewer deprecation errors, which would be less noisy.

Proposal 2: FullyValidatableConstraint

1. each type (a top-level key in a *.schema.yml file) can specify
   

   constraints:
     FullyValidatable: true
   

   , and nothing else can

2. for a given node in a config object's node tree, we only run validation constraints if its type has the FullyValidatable: true validation constraint
3. a config object (simple config or config entity) is only fully validatable if all of the config types present inside it (directly or indirectly), have the FullyValidatable: true validation constraint
4. Later, for example in Drupal 11 or 12, we could then choose to start triggering a deprecation error for corresponding to simple config & config entities, to inform that this will become required in Drupal 12 or 13. This would lead to far fewer deprecation errors, which would be less noisy.
5. See #11 + #19 for additional nuance.

So for example system.menu.tools would be validatable if system.menu.*, machine_name, required_label, label and boolean all had the FullyValidatable: true constraint.

Remaining tasks

Agree on the answer to How?.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A