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.
Move exception classes from django_evolution to django_evolution.errors.

This moves the various exception classes out of the base
django_evolution package into django_evolution.errors, in order to keep
things organized.
Optimize adding NOT NULL fields with initial values.

Previously, adding a field with NOT NULL and an initial value (to
update existing table entries) on MySQL or PostgreSQL required three
ALTER TABLE statements:

1) One to add the column (as NULL, with the DEFAULT, in order to
   update the existing entries)
2) One to drop the default
3) One to set the column to NOT NULL

The first and third resulted in a table rebuild (at least on MySQL). The
second, fortunately, doesn't. Still, this meant that many table adds
would cause MySQL to do a dump of the table, a rebuild, and a load of
the table data, twice per added field.

We now combine the first and third ALTER TABLE. We add the field as
NOT NULL with the DEFAULT, which will update all existing entries as
well, and then we drop the DEFAULT. There's now only one table rebuild
per added field.