Handle unknown migrations

[ericklaus-wf]

Fixes bad behavior when some migrations in the db table are unknown to the current sql-migrate instance. That might happen when one branch applies some migrations and a branch lacking those migrations tries to add some of its own.

This resolves https://github.com/rubenv/sql-migrate/issues/37 by choosing option 2 of https://github.com/rubenv/sql-migrate/issues/43.

Fixed behaviors:

• If most recent migration is unknown, migrate up reports "nothing to do"
  • Fix: Migrations are now applied
• If any migrations are unknown, sql-migrate status panics
  • Fix: A log warning is now emitted indicating which migrations are unknown

Some weirdness remains:

• If the latest migration is unknown sql-migrate redo reports "nothing to do"
• I'd rather that sql-migrate status include the fact of unknown statuses in the table it prints, rather than as separate warnings
  • Perhaps we could add a column to the sql-migrate status table (probably before the migration column) that includes a status code. Maybe "!" for "unknown" and "a" for "not applied"?

Is this course desirable? If so, I can resolve the pointed out weirdness either in this PR or later on.

[rickvanbodegraven]

I am probably going to see if I can use this in our project, as it might fix the exact issues we are facing. Our branching strategy has branches for each of our scrum stories, which results in migrations being written on various branches, some of which are sometimes dependent on one another. Whenever we have to review work that was done on other branches, our dockerized postgres databases get partial migrations from some of those branches, and if we then switch back to our own work, we have to delete our database (thus losing all our test data every single time) and get it migrated again (which is fast and all, but really annoying......).

Heavy support for this PR 👍