[META] Use events in Database Schema operations

I am working on a PoC for the second use case from the IS.

Here's the idea of the PoC.

We have the event service available since the very first DDL statement executed during an installation, so we can build around it. (Exception, currently - Drush does not register services defined by the database driver's module, so an event subscriber defined into it won't execute - see https://github.com/drush-ops/drush/issues/5846).

Call the following 'hook_schema_alter strikes back' if you're a fan of the Force.

1. We replace the current way of defining a table's structure via a nested array, with a structure of value objects defined in the Drupal\Core\Database\SchemaDefinition namespace. This structure is immutable and database abstract. For example, the db-specific field type array key 'mysql_type', or the 'mysql_engine' will no longer be defined here.

A table currently represented like

    $schema = [
      'description' => 'The base table for configuration data.',
      'fields' => [
        'collection' => [
          'description' => 'Primary Key: Config object collection.',
          'type' => 'varchar_ascii',
          'length' => 255,
          'not null' => TRUE,
          'default' => '',
        ],
        'name' => [
          'description' => 'Primary Key: Config object name.',
          'type' => 'varchar_ascii',
          'length' => 255,
          'not null' => TRUE,
          'default' => '',
        ],
        'data' => [
          'description' => 'A serialized configuration object data.',
          'type' => 'blob',
          'not null' => FALSE,
          'size' => 'big',
        ],
      ],
      'primary key' => ['collection', 'name'],
    ];

Will then become sth like

    new Table(
      name: 'config',
      description: 'The base table for configuration data.',
      columns: [
        new Column(
          name: 'collection',
          description: 'Primary Key: Config object collection.',
          type: 'varchar_ascii',
          length: 255,
          notNull: TRUE,
          default: '',
        ),
        new Column(
          name: 'name',
          description: 'Primary Key: Config object name.',
          type: 'varchar_ascii',
          length: 255,
          notNull: TRUE,
          default: '',
        ),
        new Column(
          name: 'data',
          description: 'A serialized configuration object data.',
          type: 'blob',
          notNull: FALSE,
          size: 'big',
        ),
      ],
      primaryKey: new PrimaryKey(['collection', 'name']),
    );

2. This strawman structure is then used to build a concrete specification of Drupal\Core\Database\Schema namespace objects or an override of any of them in the database driver module itself - via an event subscriber. Using the event system allows ANY subscriber to alter the CONCRETE specification, keeping the abstract definition untouched. This will allow defining any db-specifc property (for example, the type of index for #3397622: Adding GIN and GIST indexes to PostgreSQL databases) in the overriding classes, and we will be able to have full static analysis of the code with defined properties.

3. The CONCRETE specification is then used by the drivers' Schema class to actually perform the DDL statements necessary. Note how, most likely, a large part of what is in those classes today will be moved to the subscriber instead.

The MR is a PoC, it runs OK a number of tests locally, but fails PHPCS and PHPStan. I am not going to fix that though, I'd rather appreciate feedback on the concept.

Turning this issue into a meta. My next step will be to start working on point 1 above, which is all by itself a large endeavour. Will open a separate issue for that.

This issue being now a plan, IMHO the MR should be moved to a separate issue (if needed).