Allow third_party_settings property in the Drupal Schema format to allow storing metadata and custom module-related data

Problem/Motivation

Schema files are a very convenient way to describe and manage typed data structures and are increasingly starting to be used in various places in Drupal. So they can be used not only to validate the configuration data, but any other data too.

But pretty often, together with the type and label, there is a need to store some additional data or metadata, related to the item's display, validation, representation, or anything else.

But the Drupal Config Schema format, described here https://json.schemastore.org/drupal-config.json is pretty strict and doesn't allow storing additional properties at all, because of the rule "additionalProperties: false".

So, the allowed properties for the item are only:
- type
- label
- translatable
- translation
- nullable
- class
- definition_class
- orderby
- constraints
- sequence
- mapping

From them, nothing is suitable for storing additional item custom data and metadata.

At least, the `description` property would very much like to be available to put more detailed text in addition to the label.

There are already several modules, that use the Drupal Config Schema to build the config edit form automatically, based on the item type and label:

• https://www.drupal.org/project/auto_config_form
• https://www.drupal.org/project/schema_based_config_forms
• https://www.drupal.org/project/schema_form

They are very convenient, but all of them need to break the restriction for custom properties in the schema and use custom names to store additional data, like title, description, #description, etc.

Proposed resolution

I propose to add there the `third_party_settings` property, which is already widely used in different areas of Drupal data, so should be familiar and convenient to use.

And use the same format and API to set and retrieve the data per module name and key, like in all other places.

Alternatively, we can disable the "additionalProperties: false" to allow adding any properties as needed.

Or, at least, add the most wanted "description" property to the schema format.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet