Allow sqlite migrations for non-default databases.

[rylev]

Fixes #2607

The database will be selected by the name of the migration file. This makes the name of the migration file significant, whereas previously it was not. If the name of the file and a known database don't line up, spin up will fail with an error message.

[itowlson]

Given we have docs that use examples like spin up --sqlite @migrations.sql, and that migrations may come as a sequence of files (a la migrations001.sql, migrations002.sql, etc.), I'm reluctant to adopt this UI. Let's instead look for a more structured and specific syntax, such as --sqlite custom-db:@migrations.sql or --sqlite @migrations.sql>custom-db (the latter would presumably make shells mad but just trying to spark ideas).

[rylev]

@itowlson thanks for raising these concerns. I personally don't have strong feeling about what the right UX is here. I'd just want to ensure that it's easy to tell when the user is passing a file vs when they're passing raw SQL (since we support both). Right now the @ is used to disambiguate so perhaps we should keep the leading @. Perhaps a : between file name and databasename (i.e., @file.sql:database-name)?

[itowlson]

@file.sql:database-name works for me. Thanks!

[rylev]

@itowlson ok done!

[itowlson]

Couple of non-blocking suggestions, but before merging could you double check that the indents around lines 76-78 are right in the real code? I'm assuming a GH artifact but good to be sure! Otherwise LGTM - thanks!