Python improvements: TypeDesc
* Make a more thorough unit test
* As a result, fix tons of little problems
* More complete Python support for TypeDesc features
* Some minor (back compatible) changes to C++ TypeDesc to make it easier.
Python improvements: ImageSpec overhaul, tests, fixes
Update PDF docs
Merge pull request #663 from lgritz/lg-python

Python improvements: TypeDesc & ImageSpec
More careful with texture de-duplication.

The hash only compares input pixel values. We check a few other items in
the metadata (such as default wrap mode), but had neglected to consider
the role of the projection matrices in the metadata.  And in fact, we
had a site that routinely used EXR files for the sole purpose of having
a queryable transformation matrix (the rationale for this is more sound
than you might guess), and the deduplication was kicking in and "losing"
the different matrices because the pixels happened to be identical (all
black). And in general, we now realize that it's a little funny for the
deduplication to give us the "wrong" metadata for get_texture_info
queries. All sorts of metadata may be different despite the pixels of
the two images being identical and therefore wanting to avoid redundant
loading of tiles.

This patch does some refactoring, wherein find_tile takes a new
parameter that allows explicit "do not redirect duplicates" control,
which is used by get_imagespec and get_image_info/get_texture_info, so
that metadata queries will always return the correct results for the
named file, rather than any earlier-loaded duplicate (of pixel values).
The functions that access pixels rather than metadata (get_pixels,
texture lookups, etc.)  continue to do duplication redirects, so it
should be as efficient with duplicates as before.

Along the way, I also noticed that the per-thread "microcache" of
name-vs-texture lookups was only used when accessing via the
TextureSystem, and bypassed for apps calling ImageCache directly, nor
was it used for get_texture_info calls.  I rectified that by moving the
micro-cache check into ImageCache::find_file itself, and then making
TextureSystem::find_file (where the check previously resided) a more
simple and direct mapping of IC::find_file.  This might yield a slight
speedup for certain apps that directly use the ImageCache APIs, or
that tend to make lots of get_texture_info/get_image_info calls.
Fix some JPEG files not being recognized, now only look at the first two bytes.
TGA now converts alpha to associated on input if requested, and on output writes
the attribute that indicates if the alpha is premultiplied or not.
TGA output now always writes unassociated alpha, even if the input is associated.
This is because common applications like Gimp, Photoshop and Preview will assume
TGA files to have unassociated alpha.
Fix two issues with unassociated alpha conversion:
* PNG, TIFF and TGA input still had oiio:UnassociatedAlpha set to 1 after they
  convert the alpha to associated.
* PNG output did not take oiio:UnassociatedAlpha into account to determine if
  conversion should be done, while TIFF did.
Update testsuite references
Merge Brecht's unassociated alpha fixes
Python overhaul: ImageInput (fixes, expose new methods, unit tests, docs)
Also many of the "global" functions and symbols have been overhauled.
Python overhaul: ImageOutput (fixes, expose new methods, unit tests, docs)
Rebuild PDF docs
Merge pull request #667 from lgritz/lg-python

Python overhaul: ImageInput & ImageOutput (fixes, expose new methods, unit tests, docs)
oiiotool --origin and --fullpixels did not correctly propagate their changes
to the underlying ImageBuf's spec as well as the copy in the ImageRec.
But some other opertions would check the IB directly to determine iteration
ranges. So if you were operating on an image that was a crop window (i.e.,
different display and pixel windows), and did an --origin (or --fullpixels)
followed by another operation that used the IB's range directly, you could
end up with strangely offset results.