If two fields were being mutated in two different models in the same
mutation run, and both fields had the same name, the mutator could end
up contaminated the state for one or both. This could result in
mutations being dropped on the floor or modified in some way.

Luckily, this would all be caught when it came time to diff and
simulate, but it did mean some people couldn't upgrade their databases
if applied mutations that were getting "optimized" out.

An example that was hit in the wild is a ChangeField in one model,
followed by an AddField in another, both mutating the same field name.
The optimizer would try to condense this into a single AddField, to
prevent the ChangeField from having to apply to the database, even
though these were different models.

To solve this, we simply include the model name in all keys used for the
state tracking.

A unit test was added that reproduced the problem found in the wild.

Unit tests failed before this, as did the real-world database upgrade.

After, they both succeeded. (Well, the database upgrade failed, but due

to reasons entirely outside of django-evolution.)