Improve commit strategy

[kevlarr]

Right now migrations are performed (and recorded to the revisions table) without any explicit transaction or commit, leaving it up to the individual revisions to determine if they want to wrap their commands in a transaction and supply both begin and commit commands.

This can be problematic in several ways:

1. It offloads the responsibility of 'safety' onto the user by default, meaning if they make a multi-command revision without a transaction and it fails halfway through, their schema is now corrupted
2. It also opens the door for the individual revision to succeed but the action of recording to the revisions table to fail, in which case the database has been revised but there is no record of it, and subsequent jrny embark would re-try the revision that had already been applied

The 'simple' solution is to just implicitly wrap a revision & its recording in a single transaction, dropping the requirement that the user do so which solves (1.) above.

But that would be an issue for anyone who wants (or needs) to run a revision outside of a transaction, though - for instance creating an index concurrently. Thus there should be a way to not use a transaction for a specific revision, which leaves (2.) above unsolved.