rollback should not be unopinionated for the current execution unit

[wzrdtales]

rollback will try to happen for every action, including the one being executed right now. those will generally be a target to be skipped, except for the upcoming atomic function, which may execute multiple unsafe operations and must be reversed. The latter will require to store the state of an unsuccessful state on rollback failure as well, to provide together with the possibility to inject new rollback code afterwards a safe way to proceed on failed rollback procedures.

[wzrdtales]

fixed, but multistep commands like changeColumn will not be rolled back in their partiality. changeColumn would probably be safe to simply revert.

[wzrdtales]

although changeColumn might be safe to revert, these multistep actions are problematic. They can't be handled atomically properly. We will introduce a step counter that will automatically increase on runSql calls and append this to the driver itself. The driver needs then to take care should he have actions that are not separated from each other, but executed as a "single" action.

[wzrdtales]

another problem is when the state has historic impact. for example createTable resulting in dropTable on an already existing column. So since only the driver can tell right now if that table existed or not we need the counter + a signal. The signal would be executed reversible. B/c db-migrate executes everything assuming to be an atomic operation, this signal could help on the reverse action to take the correct step. I.e. createTable could set the signal to true when the table was created but anything else of the package command fails (this could be for example the foreignKeys added afterwards). Since a table that only added something to itself can be deleted in a single action it might be beneficial to provide a signal. But in doubt we work strictly only with the execution counter and provide an interface to that.