Add a concept of "mutators" to the evolution process.
Mutations (AddField, etc.) were previously responsible for talking

directly to the database-specific evolution operations backends in order

to generate SQL. While this worked, it was limiting, and caused

inefficient SQL.
Django Evolution's generated SQL would generate essentially one

statement per type of operation. A group of AddFields/ChangeFields would

generate an ALTER TABLE for each field, even when operating on the same

table. This would trigger a full rebuild of the table for each field,

which is extremely inefficient.
This change introduces a new design. The mutation classes now talk to

new mutator classes and now register generic operation data, instead of

generating and returning SQL. When the caller is ready to request the

SQL, the mutators will pass their list of pending operations to the

evolution operations backend, which will then determine how to handle

the operations and return SQL.
There are two types of mutators: AppMutator, and ModelMutator. Callers

will instantiate an AppMutator and tell it to run a list of mutations.

AppMutator will do the work of finding batchable mutations to a model

and construct ModelMutators. Both mutators will also work with the

mutations to mutate or simulate when appropriate.
Right now, there are no differences in the resulting SQL. This just sets

the stage for future working. The next cahnge in this series will be

able to take advantage of the operations to better optimize the

resulting SQL to batch operations to models.

Ran unit tests for SQLite3, MySQL and PostgreSQL with Django 1.4 and 1.5.
Compared SQL for an upgrade from RB 1.7 to 2.0 on MySQL, and also performed

an evolution, without problems.