ImageBuf change -- read() no longer required

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.