Introduce new structures for storing SQL statements.

This introduces SQLResult and AlterTableSQLResult, which are used to
return and store lists of SQL statements.

SQLResult has three fields: pre_sql, sql, and post_sql. pre_sql and
post_sql are used to store SQL statements that should be executed
before/after sql. These can be converted to a single list of SQL
statements with the to_sql() function.

AlterTableSQLResult extends this to also have an alter_table field that
contains a list of ALTER TABLE rules. When calling to_sql(), these are
turned into ALTER TABLE statements.

Where these structures come into play is with the next round of
optimizations. By knowing up-front what SQL statements must be executed
before/after a main set of statements, and which ALTER TABLE rules are
going to be executed, a post-processor will be able to batch operations
in an intelligent way. For example, joining all the results together to
drop all indexes before a batch of statements, combining ALTER TABLE
rules into a single ALTER TABLE statement, and then creating all new
indexes after they execute.

That will come in the next big change.
Condense ALTER TABLEs when possible.

When possible, multiple ALTER TABLE rules are now combined, resulting in
fewer table rebuilds. Adjacent ADD COLUMN, MODIFY COLUMN, and
DELETE COLUMN operations within a single batch of operations will be
condensed together.

When processing operations, AlterTableSQLResult will take the various
Alter Table operations and put them into batches of ALTER TABLE
statements. Typically, all operations in a batch will be turned into one
statement, but an Alter Table entry can set independent=True to ensure
it's part of its own ALTER TABLE, in the proper order.

generate_table_op_sql takes the operations for a model and combines
their SQL into an AlterTableSQLResult. If there are multiple adjacent
operations in a row that can be merged together (add_column,
change_column, delete_column), they'll be placed into the same
AlterTableSQLResult.

The result is a fairly compact list of ALTER TABLE statements that
trigger table rebuilds. It's still dependent on the ordering of
mutations, though.
Sort mutations by table name before applying.

Mutations that span several files end up getting jumbled, preventing the
optimizer from truly living up to its potential.

Now, when pre-processing, we rearrange all the mutations to ensure
they're grouped together by table. This should generally be safe,
as mutations don't deal with foreign relations to other tables or
fields.

This allows the ALTER TABLE optimizer to do a better job of generating
fewer ALTER TABLE statements.