Rethink the approach to migrations to better facilitate more kinds of migrations

This is a pretty big task, and probably will involve a lot of PRs, but you should do this before working on anything else.

[x] Remove TableInfo.BuilderCompat. There is a better way to represent this.
[x] Consolidate the custom test tooling related to dbinfo into libraries. The current mixture in tooling is a legacy of when the project was split into several different repos and it was quicker just to write bespoke tooling for them.
[x] Make the target_schema map in the MigrationSet use the fully-qualified java class as the key for each TableInfo. The java method name should become the key for the columns in the TableInfo. This will force a schema version for the MigrationSet and TableContext. The idea here is to be able to detect when the names of various objects change.
[x] MigrationContext should just take the schema from the highest db version rather than attempting to apply and build up the picture of the schema from the migrations themselves.
[x] TableContext.Builder should be more sane. Its main reason for existing is to defer the commitment of the current schema until all of the data has been seen. However, you've done a great job at making this complicated.
[x] Instead of generating the migrations at compile time, just generate a description of the differences between the previous schema and the target schema and give a picture of the target schema
[ ] At runtime, the DBMSIntegrator library should determine how to resolve the differences. This is going to help to separate the SQL-specific concerns of migrations and the compiler module.

ryansgot / forsuredbcompiler