Transpose now takes transposition constants as arguments. Multiple
transpositions can be sequenced together in one Transpose processor.
Auto transposition is not yet supported (PIL strips the EXIF data, so need to
find a workaround for getting that data to the processor).
The process of choosing an image format has been cleaned up and
Processors' role in determining the format has been removed.
Previously, processors would return a tuple containing the modified
image and the format. Other parts of IK overrode PIL's Image.format
with the target format, although that had no effect on PIL and the fact
that it didn't throw an error was just lucky.
In the old IK API, processors (like `Transpose`) were able to access
the file by inspecting the model instance (which carried an options
object that specified the attribute name of the ImageField from which
the file could be extracted). Since the new API allows for multiple
ImageFields (and because IKOptions have been removed), it became
necessary to provide more information. Initially, this was accomplished
by passing the spec to `process()`, however with the addition of
ProcessedImageField, it became clear the a cleaner solution was to pass
only the field file (ImageSpecFile or ProcessedImageFieldFile).
This keeps the ORM stuff (fields, etc.) out of the `ImageProcessor` API
but (because field files, not just regular files, are passed) the
average hacker can still have their processor make use of model
information by accessing the model through the file's `instance`
property.
The Format processor was really a special case and didn't do any
processing at all. Instead, ImageSpec just knew to look for it and
responded accordingly. Therefore, it's been replaced with a `format`
property on ImageSpec. This warranted a deeper look at how the format
and extension were being deduced (when not explicitly provided); the
results are documented in-code, though the goal was "no surprises."
