Add Replacers.decomposing(): Replacer to decompose a compound statement into equivalent individual statements

[lukaseder]

Some dialects support compound DDL statements, where a single statement changes multiple things atomically. For example:

-- Various dialects support adding multiple columns in one go.
-- There are different syntaxes for this, here's one possible syntax:
ALTER TABLE t
  ADD col1 INT,
  ADD col2 INT

-- MySQL supports adding comments with columns and tables directly:
CREATE TABLE t (
  i INT COMMENT 'column comment'
) COMMENT 'table comment';

It would be useful to be able to decompose a query into multiple queries to result in this:

ALTER TABLE t ADD col1 INT;
ALTER TABLE t ADD col2 INT;

CREATE TABLE t (i INT);
COMMENT ON TABLE t IS 'table comment';
COMMENT ON COLUMN t.i IS 'column comment';

While the original dialect may not be able to run the decomposed queries, the decomposition is still very useful in use-cases like the DDLDatabase, see #12779.

The API of decomposing queries is part of the commercial SQL transformation feature set, but the implementation for this feature should be offered also in the OSS edition to benefit the OSS version of the DDLDatabase.

This feature is part of a bigger task, see #9645

Decompositions implemented so far:

• MySQL inline column COMMENT to COMMENT ON COLUMN
  • In CREATE TABLE
  • In ALTER TABLE (will be done later)
• MySQL inline table COMMENT to COMMENT ON TABLE
• MySQL inline INDEX definition to CREATE INDEX

Decompositions to be considered (perhaps using some configuration, similar to the DDLExportConfiguration)?:

• Inline constraint specifications to ALTER TABLE .. ADD CONSTRAINT (turned off by default) won't be done for now)

Decompositions that won't be considered:

• CREATE TABLE .. (col1, col2) to CREATE TABLE .. (col1); ALTER TABLE .. ADD col2

---

See also:

• Add Settings.mergeDDLStatements and Settings.mergeDMLStatements #9503 (the inverse operation)

[lukaseder]

The operation is not very important, so putting it on the ubiquitous Query type generates "API noise". Since it is a SQL transformation, which is best implemented using QueryPart::$replace, it's probably more interesting to place this in a new Replacers type.

[lukaseder]

This replacer hasn't been too useful so far, but we can re-use it as need arises in the future.