We have two places in Django Evolution where we need to create

representations of data (everything from primitives to class references

to object instances): The stored database signature, and the evolution

hints.
We also need to take signature data and turn it back into usable

objects.
Previously, this was being done by some utility functions within the

mutation and signature layers, but with growing complexity in database

options for modern versions of Django, a new approach was needed.
This change introduces centralized serialization code for this. There

are serialization classes registered for all types of content that we'd

want to represent, which handle serializing to signatures, serializing

to Python code, and deserializing from signatures.
The three functions provided are serialize_to_python,

serialize_to_signature, and deserialize_from_signature.
Behind these is a couple of registries mapping types to the

serialization classes responsible for the implementations.
Django "deconstruction" support is available, which is how Django

objects serialize themselves. There's support for this, and explicit

support for working around changes they've made to this for Q query

objects. We now support all variations of this format.

Unit tests pass on all supported versions of Python and Django.