When creating models, EvolveAppTask was generating and storing the SQL

for an entire model creation, which included not just the CREATE TABLE

but any deferred constraints. Each batch of SQL statements would later

be executed in order. If any of these SQL statements contained

constraints that referenced a table introduced by a subsequent task, the

SQL would fail to execute, because that table wouldn't have existed yet.
What's supposed to happen is that the deferred statements are executed

after the tables are created. Hence the "deferred" part. The way the

logic worked, this wasn't possible. SchemaEditor knows how to do this

correctly, as does our legacy logic for Django 1.6, but they require

having the full list of new models (not just a subset) passed to them.
This change redoes this logic to gather all models up-front and to

generate the SQL in one go, ensuring that the ordering of statements is

correct. The only real behavioral change introduced from this is that we

have to emit all creating_models signals up-front, and then emit all

created_models after all models are created, rather than emitting

these in pairs. This means that callers can't expect to receive them in

that order.
It also means that the evolve command will be listing all

"Creating new database models for ..." up-front, rather than when each

model will be created. It's an annoyance, but hopefully a mostly

harmless one, and is necessary without a much larger reworking of how

this SQL is generated.

Unit tests pass for all supported databases.
Verified this fixed an issue with setting up a Review Board database.