Support transactional migrations for all the ORM providers

[cusspvz]

Is your feature request related to a problem? Please describe.
Each migration is currently responsible for managing the transactions happening within the migration. This allows the migration to include more than one transaction, but also makes it harder to write simpler migrations that only require a single transaction.

Describe the solution you'd like
I'd like to see some sugar behavior from ABMT, both in terms of API and default behavior:

1. API - The Core should expose or extpand an interface for ORMs to provide transaction control basics, the ORMs should be responsible for implementing that transactional API.
2. Behavioral - The API should include a lazy-loaded transaction generator that the engine can use to generate a transaction prior to a migration execution. If the generator caches the latest lazy-loaded transaction, then it could also be a good idea to have it assessing if it should be reusing the cached transaction, if the existing cached version has changes and needs to be closed, and if a new one should be generated (or initialized) and returned for use within the migraiton.

Additional context
Different toolsets have different rules regarding transactions. Umzug doesn't manage transactions. Hasura migration system wraps all the SQL migrations within a transaction. We should consider the pros and cons of all the approaches and ensure that ABMT offers both flexibility, and simplicity.