Fix ImageBuf vs ImageCache out-of-date image problem

[lgritz]

ImageBuf uses ImageCache underneath. But this can lead to the following
unexpected behavior if you don't understand this:

1. Make an ImageBuf for an image, read it (even just header info).
2. Done with it, destroy the ImageBuf.
3. Some other part of the program, or even a different process, changes
   that file on disk.
4. Make another ImageBuf with the same filename, thinking you're getting
   the updated image, but in fact it's relying on the cached representation
   which doesn't contain the changes made in step 3.

So these tiny changes try to make this much harder to shoot yourself in the
foot:

• New ImageBufs automatically call cache->invalidate on the filename
  before they start reading, to ensure that if the file has changed on
  disk, anything in the cache is invalidated.
• When you destroy or clear an ImageBuf, it calls cache->close() on the
  file, to release the handle (especially helpful on Windows, where an
  open file handle can lock the file to other processes).

There is a chance that some image operations will have degraded
performance, if you are mixing direct ImageCache use (including
TextureSystem) and ImageBuf reads of the same files -- since creating
and destroying the IB's will flush tiles from the cache and close cached
file handles. But I think that this should not be a problem in practice,
since most apps that are heavy users of ImageBuf (like oiiotool) aren't
heavey users of IC/TS, and vice versa. And eliminating this confusing
behavior is probably more important than occasional over-eager
invalidation of the cache.

Also clarify in the docs (and imagebuf_test) that if you use the
variety of ImageBuf ctr where you give it a custom ImageCache, it's
important that the ImageBuf outlives the ImageCache, as it is a
non-owning reference.

Fixes #1987

Signed-off-by: Larry Gritz lg@larrygritz.com

[lgritz]

Does anybody think this is a bad idea?