[FEATURE]: Make it possible to enforce various migration steps in types

### Feature hasn't been suggested before.

- [x] I have verified this feature I'm about to request hasn't been suggested before.

### Describe the enhancement you want to request

Certain types of migrations are not type safe and require manual codebase searching, even though there is nothing inherent to them that prevents static type based analysis. For a prime example see the typical process for deleting a column:

1: Stop reading from the column
2: Add default or make nullable if not already
3: Stop writing to the column
4: Delete the column

Doing steps 2/3 when step 1 is incomplete is unsafe and will lead to runtime errors/bugs, and doing step 4 before 1/2/3 are all done is also unsafe, but yet the completion of step 1 or 3 is not possible to enforce statically with drizzle.

Both step 1 and step 3 can be incomplete for reasons that aren't even trivial to grep / IDE check. As any `select()` or `select(...getTableColumns(...)...)` anywhere in a query that references the table will break step 2/3, and any `{ columnName: ... }` in an insert values or update set statement will break step 4. Things like trying to grep for `myTable.columnName` or similar is useless.

Being able to mark a column as unreadable or unwritable or both without actually deleting it would make the above pretty trivial and hard to mess up. Even ignoring the error prone aspect it'd also just be convenient to be able to keep using `select()` instead of either using `select(readableTableCols)` everywhere all the time or switching back and forth between the two whenever a column deletion happens.

This is not the only possible improvement for migration safety, just a good commonly needed example. For an additional example being able to have the read and write types for an enum differ to enforce writing a narrower set while making sure readers can handle a wider set. Generally more precise control over what values are allowed to be written and read that may differ from the actual db-side column migration type is needed, in a way that of course doesn't allow for a regression in safety such as allowing you to write values that are outside the db type, widen reads and narrow writes and never the opposite.