This PR is part of the WIP for migrating from dictionary configs to typed & validated configurations (see #3193 for an overview).

Introduces a config versioning and migration system for configurations. This facilitates easier changing of configuration schemas while keeping backward compatibility and reducing risks of missing-field-errors.

Changes

• core/config/versioning: a registry for keeping track of migrations and adding changes over subsequent configuration versions. No changes are implemented yet, only placeholders, preparing for migration from v0 to v1
• core/config/migration_mixin: the MigrationMixin class can be used as mixin for dataclasses to facilitate easy migration. It enables automatic loading and validation of earlier configurations into the current versions format.
• tests/core/config/test_versioning.py for versioning and MigrationMixin.

Usage
After applying changes to the configuration dataclass (e.g. renaming of fields, or changing value types), the CURRENT_CONFIG_VERSION should be incremented accordingly (e.g. from 0 to 1). The corresponding transformations from the old field to the new field can be added to a migration function. e.g. migrate_v0_to_v1.

For instance when deciding that value 'MULTI!' for field bodyparts should be converted to an empty list, one can add the following transformation:

@register_migration(0, 1)
def migrate_v0_to_v1(config: dict) -> dict:
    """Migrate from unversioned/legacy config (v0) to v1.
    """
    normalized = config.copy()
    if normalized.get('bodyparts')  == 'MULTI!':
         normalized['bodyparts'] = []
    return normalized