Introduce SchemaDefinition-based alternatives to Schema::addField and ::changeField

Problem/Motivation

Schema::addField() and ::changeField() are a bit weird in the sense that they require in input parts of the schema definition, duplicating information that is already present in the schema definition itself. With the new SchemaDefinition structure, we could just pass the target structure and determine the operations needed.

Proposed resolution

Introduce two new methods to Schema:

• addTableColumnFromDefinition(SchemaDefinition $targetSchema, string $tableName, string $targetColumnName, ?Expression $initializationExpression = NULL): void
• changeTableColumnFromDefinition(SchemaDefinition $targetSchema, string $tableName, string $targetColumnName, ?string $currentColumnName = NULL): void

Also do some additional ancillary changes:

• Support an initialization SQL expression when adding a column, useful for populating existing rows.
• Automatically handle dropping and rebuilding of indexes, unique keys, and primary keys affected by column addtion/changes.
• Add ::columnNames() helpers to Table and KeyBase.
• Strengthen Table validation to ensure keys reference existing columns.
• Add Schema::uniqueKeyExists() to the schema API, filling a surprising gap.
• Improve PostgreSQL handling of transformed index/constraint names.
• Add MySQL handling for failures when dropping primary keys.
• Adjust SQLite table rebuild logic to preserve keys/indexes.

And add relative tests.

In the future, these methods could potentially replace :addField() and ::changeField() once all the conversions to SchemaDefinition will have been made.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet