Reversable DDL

## Feature Request

**Is your feature request related to a problem? Please describe:**

When a DDL is completed, there may be issues with connected applications (not able to use the new table definition). There are then two ways of solving it:
- Fix the application
- Alter the table again

These scenarios are common reasons for outages.

**Describe the feature you'd like:**

If the DDL was easy to rollback/revert it would provide a very fast way of resolving such scenarios.

Some online DDLs work by having both the old and the new table structure in sync, and in the last stage it removes the triggers where the the data is updated in both the old and new table structure.

If the double writing triggers were allowed to stay for some time after the ALTER TABLE finishes, and the cleanup of the old data parts is delayed, then it would be easy to switch between both the new table structure and the old table structure by simply changing the metadata of the table.

When a configurable time has gone after the ALTER is completed (or manual telling the cluster) it will remove the double writing triggers and cleanup the old data parts.

This could even be used as an option instead of transactional DDLs.

**Describe alternatives you've considered:**

Using pt-online-schema-change with --reverse-triggers and --no-drop-old-table

**Teachability, Documentation, Adoption, Migration Strategy:**

Whenever there is a risk that a DDL will affect applications and risking an outage.

Allow to test a new table structure to test how applications is affected
- Do the DDL, let the applications run with the new table structure and see if they have any issues, then revert the DDL