CHECK constraints not dropped if one migrates from Boolean or Enum to another type

first described in #605. #605 will address the detection of boolean -> TINYINT which is the biggest problem. this issue will track if we decide we will try to DROP the CHECK constraints generated for boolean and enum. this drop could occur either as part of the operation itself, or could occur as autogenerate adding an explciit "drop_constraint()" op to the migration script. however, it becomes very complicated because without a constraint naming convention in place, there's no way to really automate this without doing some kind of search of all the constraints to find one that involves the target column and looks like the constraint that we added (or any check that involves the column alone and no others). That in itself would need to be at op time, not migration time, because again we wouldn't have a deterministic name of the constraint.

overall it seems a little like a "just put a note / warning and needs manual intervention" thing.

maybe Alembic shouldn't allow you to create such a type without the constraint having an explicit name. again not sure.

Start by reviewing issue #605 and the migration and autogenerate behavior described here. Decide whether constraint removal belongs in the operation or as an explicit drop_constraint() migration operation, and define how unnamed constraints should be handled; done requires a documented, testable behavior for Boolean or Enum type changes.