Add dump column in schema_migration and sync command line argument

[Sentenzius]

I've added 2 new features to dbmate that can be helpful for many.

1. I added a column in migration_schema named 'dump'.

This column contains the 'down' migration that need to be executed to rollback the applied migrations. This is useful in this scenario:

• We have installed a software compiled in the year 2025.
• For some reason this software isn't stable, we've got to rollback to a software compiled in 2023.
• Both during install use dbmate.
• The older software even checking the schema_migrations table, wouldn't know how to rollback the migrations done in 2024 and 2025, because the 2023 installer doesn't have those .sql files.
• Storing the dump of the 'down' queries give older installers to correctly rollback future migrations.

2. I added a command line argument named 'sync'.

This command automatically execute all 'up' migrations available in one shot, or rollbacks future migrations found in existing database thanks to the 'dump' column added in schema_migrations.

P.S. In case the current schema_migrations doesn't have the 'dump' column it is added, and it would be empty at the beginning. But if the .sql files provided to dbmate contain the migration versions already applied, dbmate will also populate the 'dump' column accordingly. So it would work also with existing database. If this feature is not used, does not harm.

P.P.S. Works perfectly with MySQL, I tried also to adapt code of others languages, they compile all, but I don't have tested them.

[dossy]

Applying down migrations is generally a dangerous procedure that results in irreversible data loss. Making it too easy to unintentionally perform them through a "synchronize" action feels especially dangerous.

The idea of letting an older version of software destroy data used by a newer version seems to me like a foot-gun of epic proportions.

If there are others who have actual use cases that require this functionality, they should speak up in favor of this change. I do not, so I'll recuse myself.

Thanks for the thorough work on the PR, though.

[Sentenzius]

Yes, the downgrade can expose to loss of data, but in our use case sometimes is necessary.

Even if the PR will be rejected your answer @dossy has been useful because I unserstood better how to use down migrations!

Because our purpose of the migration is to adapt database to software changes. But we apply down migration for example because a stored procedure isn't compatible with previous versions.

Instead for example if a migration add a column, and in that column is present important data, a down migration shouldn't remove that column. It won't use it, but should delete that.

Previously instead I've always thought down migrations as the contrary of up migrations.