Configuration schema & required values: add test coverage for `nullable: true` validation support

Problem/Motivation

Quoting @bircher, maintainer of https://www.drupal.org/project/config_split, https://www.drupal.org/project/config_filter, etc., after I asked him What concrete things have gone wrong due to bugs in configuration, especially if they were caused by overriding/splitting/… — any of the advanced Configuration Management things?

what can go wrong, well sorting mostly... oh and to know if a key is required or not. So sometimes when a value is null or the array empty we can omit the key and sometimes not

👉 This issue aims to address the "sometimes when a value is null or the array empty" part. See #3364108: [PP-1] Configuration schema & required keys for the other part.

The following things in Drupal core's config schema are using nullable: true:

entity_reference_selection.default:target_bundles (which is type: sequence) since #1978714: Entity reference doesn't update its field settings when referenced entity bundles are deleted in 2015
editor.editor.*:image_upload.max_dimensions.width and editor.editor.*:image_upload.max_dimensions.height (both of which are type: integer) since #2644838: Add test coverage for the editor's max dimension setting, and fix its message when one dimension is unrestricted in 2016
views.display.page:use_admin_theme (which is type: boolean) since #2719797: New option for Views page displays to use the admin theme in 2023.
… and several more since this issue was opened: theme_settings:logo.url, media.settings:iframe_domain and update.settings:fetch.url (since #3361534: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate)

It's that first one that introduced nullable: true support in the first place. It also added this to \Drupal\Core\Config\Schema\SchemaCheckTrait::checkValue():

      // Array elements can also opt-in for allowing a NULL value.
      elseif ($element instanceof ArrayElement && $element->isNullable() && $value === NULL) {
        $success = TRUE;
      }

\Drupal\Core\Config\Schema\SchemaCheckTrait::checkValue() already allowed NULL on all primitive types (integer, string, etc.).

However, despite the presence of

    // Add the NotNull constraint for required data.
    if ($definition->isRequired()) {
      $constraints['NotNull'] = [];
    }

in \Drupal\Core\TypedData\TypedDataManager::getDefaultConstraints(), no validation constraint violations are generated when calling

$typed_config->createFromNameAndData($config_name, $config_data)
  ->validate()

This would enable modules like https://www.drupal.org/project/config_split, https://www.drupal.org/project/config_filter et cetera to work more reliably.

Steps to reproduce

See included test coverage.

Proposed resolution

Whenever nullable: true is present, make \Drupal\Core\Config\TypedConfigManager::buildDataDefinition() mark the built data definition as optional
Add test coverage to prove that when nullable: true is present, setting a value of NULL is considered valid, for all data types. And if it's not set, a value of NULL should trigger a validation error.
Do this for ALL configuration: ALL configuration that has a non-optional value that is missing should trigger a validation error.
BUT:
1. In this issue, only fix invalid config_test.* configuration, to first get the infrastructure in place.
2. Add \Drupal\Core\Config\Schema\SchemaCheckTrait::$ignoredPropertyPaths and ::isViolationForIgnoredPropertyPath() to ensure we know which configuration in core is invalid, which also makes it easy to create follow-up issues per pattern, module or config entity type — just like we did for #3361534: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate (see #15).
3. … which also makes it possible to reduce disruption: #3361423: [meta] Make config schema checking something that can be ignored when testing contrib modules