ImageBuf change -- read() no longer required, and other minor API changes.

It always bugged me that an ImageBuf needed an explicit read() (or, if
you only needed spec information, init_spec()).  The constructor didn't
do it because we wanted explicit control of some things.

This change makes the init_spec() and read() entirely optional, as long
as you are ok with an "ImageCache-backed" buffer.

Basically, it keeps track of whether the spec and pixels are valid, and
any API calls that require the spec automatically do an init_spec() if
not already done, and any API calls that require the image to have been
read will call read() internally if not already done.  In theory, there
is a very tiny performance hit for constantly checking the bool that
indicates whether these have been done, but compared to most things you
do with images, that's pretty minor.  And is significantly simplifies
code that uses ImageBuf in straightforward ways. For example, a "poor
man's iconvert" just looks like this:

    ImageBuf in ("in.tif"); // doesn't read yet...
    in.save ("out.exr");   // Auto-read here implied by needing pixel vals!

Of course, you are welcome to use read() explicitly, as you did before,
and that's what you need to do if you want to force a fully local read
rather than using the ImageCache, or if you want to force translation to
a specific data format that's not what's in the file or part of the
ImageCache default behavior (e.g., force conversion to UINT16, no matter
what the file's pixel data type is).

Mostly this is nice because the kind of simple examples that we put in
the docs are a lot nicer to read without all those extraneous read() calls
being required everywhere.

Also changed 'save' to 'write' for consistency (for now, there's still
a save() function that's a symonym for write()), and added some constructor
variants that make it optional to supply a name at construction time
for wrapped and writeable ImageBufs.