support for change migrations

[jenseng]

Spawned from #26

Right now you can't do create_trigger in a change migration (only up/down). This is because create_trigger will drop a trigger of the same name if it already exists before creating the new one. This makes reversing the migration problematic, since the correct behavior depends on the state of the schema before that migration. So create_trigger per se contains insufficient information to tell you how to reverse it.

It's probably worth changing that behavior and introducing something like force: true for use in schema.rb (like how rails auto-drops tables before creating them), and defaulting it to false for migrations. That would make the behavior of create_trigger more predictable and would allow it to be reversible (so long as force: false)

One problem to solve is how to make the upgrade process painless, since there are probably migrations in the wild that depend on the current create_trigger auto-drop behavior.

We could probably also support drop_trigger à la drop_table (i.e. full definition with a block), otherwise there's insufficient information to reverse it.