DatabaseState has previously tracked indexes and unique indexes

together in a single dictionary. If there were normal and unique indexes

with the same name, they'd conflict.
While it makes sense for them to conflict, this actually poses an issue

on Django 1.6, at least in unit tests. Django 1.6 doesn't consider the

unique flag when generating an index name, meaning that two indexes

for the same field with different unique flags end up generating the

same name.
If applying an evolution that, say, turns off db_index and turns on

unique, we end up in a state where DatabaseState is aware of the

previous index from the db_index and returns it when looking to see if

there's a unique index present. The query we have is really asking "is

there a unique index for <columns>" and, if no, adding the unique index

for tracking. Since both used the same names, these lookups failed.
Django 1.7 and higher use different naming for unique indexes, so the

problem doesn't exist there. While ideally we'd just override the index

name generation for 1.6, we do need to be compliant with Django 1.6's

built-in logic or other things will fail. So separating out this state

is the cleanest (and hopefully safest) way of ensuring we can look up

and apply the correct state.

All unit tests pass for all versions of Django.