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.