DB driver operations should be atomic

[dhui]

Describe the Bug
Not all DB driver operations are atomic as show by #150

Operations that aren't locked:

• Schema/version table management. e.g. all CRUD operations.

Steps to Reproduce
Creating multiple instances of a DB driver (which will attempt to create the schema/version table)
See test added in this PR: https://github.com/golang-migrate/migrate/pull/150/files#diff-5cc52c39a5031732bc6d3821ffc558e6

Expected Behavior
All DB driver operations should be atomic

Migrate Version
N/A

Loaded Source Drivers
N/A

Loaded Database Drivers
N/A

Go Version
N/A

Stacktrace
N/A

Additional context
The fix for all drivers might be complicated. Not all DB driver lock implementations are reentrant. Some DB drivers implement locks using other tables which complicates the fix.
It may be cleaner to expose schema/version table operations in the new DB driver interface and provide guidance on lock implementations.

[dhui]

Schema version table creation is locked in Postgres after this PR: #150
All other DBs will have their schema version table creation locked after this PR: #173

Locking schema version table creation created a bug when dropping: #164
#173 fixes the "dropping bug" but does so by not re-creating the schema version table. This has the side-effect where after calling database.Driver.Drop(), you'll need to recreate your database.Driver instance using database.Driver.Open(). If you're using a migrate.Migrate instance, that'll also need to be re-created after calling migrate.Migrate.Drop() for the same reason.