Change how we generate new and default index names.
Django Evolution has historically made some decisions around index names

that weren't quite correct. It used to assume that existing and new

index names were named the same way, and this logic was tied to the

Django version. That mean that if you upgraded from an older version of

Django to a newer one, it would assume new defaults.
Now that Django Evolution can introspect the database for index names,

we no longer need to guess index names everywhere. We can assume them in

most cases. We also can pick our own names for brand new indexes. So,

get_new_index_name no longer has to do Django version checks, and can

instead generate a safe, unique name. This helps with naming conflicts

for new indexes on some databases.
The unit tests still need to guess a name, though. This is because the

tables are created in a transaction, and indexes can't be looked up yet.

MySQL and SQLite (and their Django database backend modules) have the

same format for default index names, but Postgres has its own format.

So, some of the old guessing logic lives on in a new function,

get_default_index_name. This is used only for unit tests, and it's a bit

smarter and more compact than the old logic.
The end result of this change is that new index names are more

predictable, future-proof, and less likely to conflict with any existing

index names in the database.

Unit tests pass for SQLite3, MySQL, and PostgreSQL on Django 1.3, 1.4 and 1.5

(with the exception of a completely unrelated breakage on 1.3 that has

to do with a silly and useless assumption in a separate test).
I was able to evolve my SQLite 3 database for Review Board with this change

plus an upcoming change when adding a unique_together entry that was

previously conflicting with a default entry.