Fix ImageBuf spec vs nativespec confusion over the data format.

Recall: ImageBuf.spec() is supposed to describe the data in the buffer (or held by the ImageCache, if it's a cache-backed IB), whereas ImageBuf.nativespec() is supposed to describe the data in the file itself.

It turns out this was subtly broken all along -- in cases where you called init_spec(), spec().format held the data type of the file after that call, but after a full call to read(), it would be changed to reflect the data type of the buffer.

This did not match the documentation or intended design of spec vs nativespec, but we never noticed, and in fact there were places in the code that (unknowingly) took advantage of this chain of events.

When, earlier this week, I committed changes that remove the need to ever call init_spec() and read(), instead doing these actions automatically and lazily when other API calls first need the data in question, a bunch of icky bugs popped up, revealing this confusion.

This patch mostly fixes the situation.  It is VERY important for apps to keep straight whether it's spec() [the buffer] or nativespec() [the file] that they want to be calling for any particular purpose.

There is still one way things can be confusing: If you create the IB, then reference spec() -- which will reflect how it will look in the ImageCache, then force a call to read() to force a fully local read rather than use the cache... at that point, spec().format will change to reflect the buffer that you read.  I don't see how to avoid that, unless we switch to a model where the IB constructor fully specifies at that time whether the IC will be used or whether the file will be fully read locally.  I'll mull that over for possible later revision.