Add intelligence for looking up and tracking indexes during evolution.
Django-evolution used to make a lot of assumptions about index names and

their existence, which was a problem when dealing with anything

non-standard or from older databases. Django has changed the default

names for indexes over time, and it's not uncommon for older projects to

have stale index names or even custom indexes generated manually.

Furthermore, things would simply fail if an evolution operated in some

way on the same index more than once.
Now that indexes are loaded into the database signature prior to

evolution, we have more information to work with. The evolution

operation backends for each database now track changes to indexes by

adding to or removing from the database signature.
It also does a better job of determining which index name to operate on,

by looking up from the signature instead of assuming it's named a

certain way.
Much of the evolution operations code has been cleaned up as a result.

Some of the main functions (such as create_index) have been split into

the public function (which will now deal with looking up or manipulating

the list of indexes) and pure SQL generating functions (designated by a

`_sql` suffix). This helps keep all the main logic in common.py and not

the database backends.

Unit tests pass for SQLite, MySQL and PostgreSQL, on Django 1.4 and 1.5.