Improve auto migration

[taqenoqo]

So far, only the following migration steps have been possible:

[[Migration a1 a2 pure, Migration b1 b2 pure]
, [Migration a2 a3 pure, Migration b2 b2 pure]
, [Migration a3 a4 pure, Migration b2 b3 pure]
]

This pull request makes it possible to write the following flexible steps:

[[Migration a1 a2 pure, Migration b1 b2 pure]
, [Migration a2 a3 pure]
, [Migration a3 a4 pure]
, []
, [Migration b2 b3 pure]
]

[exaexa]

Hi @taqenoqo, this looks IMO OK to go in as is; some minor questions:

• adding the extra constructor on Migration makes the lambdas that match e.g. Migration _ to _ spew a warning (example below), is there some nice way to squelch that? I see the other possibility essentially cannot get there but it's still a warning.
• eventually, we would also have drop-table migrations?

Warning ex.:

...
src/Database/Selda/Migrations.hs:131:22: warning: [GHC-62161] [-Wincomplete-uni-patterns]
    Pattern match(es) are non-exhaustive
    In a lambda abstraction:
        Patterns of type ‘Migration backend’ not matched:
            MigrationCreateTable _
    |
131 |       diffs <- mapM (\(Migration from _ _) -> diffTable from) ms'
    |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

src/Database/Selda/Migrations.hs:137:9: warning: [GHC-62161] [-Wincomplete-patterns]
    Pattern match(es) are non-exhaustive
    In an equation for ‘replaceIfSameTo’:
        Patterns of type ‘Migration backend’ not matched:
            MigrationCreateTable _
    |
137 |         replaceIfSameTo m@(Migration _ to _) =
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

...