Introduce the concept of "producers"

[j4mie]

This is a big conceptual shift.

Binding the name to the value by having projectors return dictionaries turned out to not be ideal. It was conflating the lower layers (getting values from instances) with the higher layers (presenting the data) because those projector functions had to give a specific name to the value they returned. This necessitated the introducion of "aliasing" throughout the API, whereby the key returned from the projector was replaced with another one. Aliasing was just a hack around the root problem - the names should only be bound in specs.

This PR introduces the concept of "producers", which are functions which just get a single value from an instance. These are then later wrapped to form projectors.

The recommended way to use django-readers is now to write custom producer functions (rather than projector functions), and then mount them explicitly in a spec under a given key:

def produce_upper_name(instance):
    return instance.name.upper()


upper_name = (qs.include_fields("name"), produce_upper_name)


prepare, project = specs.process([
    {"upper_name": upper_name}
])

This makes the internals of the library a little bit more complicated, but the end-user experience is actually less confusing. And the only actual breaking-backwards-compatibility change (I think) is the removal of the alias functions.

[pmg103]

Yeah I think this is an improvement

[pmg103]

I find this extremely verbose but if its internal only I guess its better to be explicitly very explicit and explicit and verbose and extra verbosely explicit