database: Improve our approach to migrations that add or remove columns

[jsha]

Our approach to migrations that add or remove columns is documented at https://github.com/letsencrypt/boulder/blob/master/docs/CONTRIBUTING.md#gating-migrations. Right now that process isn't doing a good enough job ensuring the correctness of our code, as evidenced by #4880. We should come up with an alternate way to approach the problem that has more built-in protections.

[aarongable]

Gist of the idea: the issue is that SELECT * uses the database as the source of truth for what fields exist, while SELECT foo, bar uses the statement there as the source of truth, and Get() and Insert() use the Go struct's fields as the source of truth. We'd like to standardize on always using the same thing as the source of truth, and we'd like that to be the struct.

This suggests that we should rewrite Select() to behave more like Get(), i.e. to inspect the destination object and auto-generate the list of columns from its fields. Then we can control exactly what columns we read (and write, when using Insert()) just by changing the object being read into (or written from). We can then ensure that all database reads use our version of Select(), and that we never spell out lists of field names by hand.

However, this has the issue that, if we add a field to a struct before we add it to the database, Select()s will fail. Therefore we should also guard struct fields behind feature flags. We have two proposals for how to do this:
a) Add a new kind of struct tag, which instructs our version of Select() to inspect a feature flag when deciding whether or not to list the corresponding column name; or
b) Have the method which calls Select() use a feature flag to decide whether it should instantiate an (e.g.) OrderModelv1 or OrderModelv2 as the destination of the Select() call.