Split a single migration into multiple files

[0xjac]

Is your feature request related to a problem? Please describe.
Some of our migration files are very large. (E.g. The initial up migration file, defining most of the schema, significant refactors of the data model, collapsing of migrations, etc.)

Describe the solution you'd like
The possibility to split a single migration into multiple ordered files (whilst keeping all files as a single migration version).
Essentially this would require modifying the file name format from:

{version}_{title}.up.{extension}
{version}_{title}.down.{extension}

to:

{version}_{part}_{title}.up.{extension}
{version}_{part}_{title}.down.{extension}

Where part is an optional incrementing integer for its migration version. This would result in something like:

0001_01_users.up.sql
0001_01_users.down.sql
0001_02_base.up.sql
0001_02_views.down.sql
0002_triggers.up.sql
0002_triggers.down.sql

From a clean database, running all up migration would run the files in the following orders:

1. 0001_01_users.up.sql
2. 0001_02_views.up.sql
3. 0002_triggers.up.sql

Note that:

• It should not be possible to run some of the files for a migration versions. All of them must be run together. (Otherwise, it would just be separate migrations...)
• Splitting the code across file obviously implies separate transactions (when applicable).
• If a version specifies parts for up or down, then all files for that migration must specify part in order to have a deterministic order for the files. (I.e. you cannot have 0001_01_users.up.sql and 0001_views.up.sql.)
• Part numbers can be skipped in one direction with respect to the other direction, similar to migration versions.
• By keeping file parts optional, existing migration files will continue to work as expected, thus maintaining backwards-compatibility.

Describe alternatives you've considered

1. Simply split the large migration into multiple migrations.
   This does not work for me, as there is a risk to leave the DB in an inconsistent state due to user error, as it is unclear which migrations should always be applied in a group.
2. Use an external tool to generate a single migration file from multiple files (either by simply concatenating multiple files or using templates).
   This does not work either. Besides the overhead of build (and remembering to build) the migration files, this introduces a lot of complexity and undermines the consistency of the migration files.

Additional context
Splitting large migrations into smaller files might mitigate #300.