Update INSTALL to add libpng requirement

I'm trying to get up and running with OSL and OIIO on a fresh 
Ubuntu Lucid VM, and was unable to compile without libpng.

ImageBufAlgo::compare and idiff improvements.

Change the IBA::CompareResults failure and warning counts to imagesize_t so
they can't overflow int for very large images.

Have IBA::compare() give a sensible error (rather than an ASSERT) if the
images aren't float.

Add a careful unit test for IBA::compare() to imagebufalgo_test.cpp.
Add split and join to Strutil
getattribute("format_list"): return a comma-separated list of supported formats
openexr: Don't suppress output of all metadata with a colon; only those
whose prefix is the name of a format.
CHANGES and other docs fixes
Add ImageOutput::open(name,subimages,subimagespecs[])

This alternate open() method allows you to pre-declare the number of
subimages and their specifications, some formats need this when first
opening a file for output.

Add supports("appendsubimage") to indicate an ImageOutput that doesn't need
this, i.e., can just use open(name,spec,AppendSubimage) repeatedly without
giving notice in advance of the subimages.
Change oiiotool to use the new "open with subimages specified" API call
in order to accommodate file formats that need this call rather than
appending subimages without prior declaration.
Support for OpenEXR 2.x "multi-part" files (and build support for OpenEXR 2.0).

This basically presents as OIIO "multi-image" files (subimages), but the
hitch is that when writing, OpenEXR needs to know the number of subimages
and all the subimage specs when the file is first opened.  Luckily, we
just added a new open() API call flavor for this purpose, so we use it.
testsuite/openexr-v2 tests OpenEXR 2.x features, also change OpenEXR
testsuite entries to expect images in ../openexr-images, not
../openexr-images-1.5.0.
Fix bugs in OpenEXR multi-part input
Small error reporting improvements, found along the way.
Alter APIs to support 'deep' reading and writing.

This includes:

* 'bool deep' field in ImageSpec, indicating a deep image.
* DeepData helper class for holding the sample counts, pointers, and
  data block, passed from/to the read_* and write_* deep functions.
* ImageInput: read_native_deep_scanlines and read_native_deep_tiles,
  which should be overloaded by any format reader supporting deep images,
  and read_native_deep_image (implemented in terms of the others).
* ImageOutput: write_deep_scanlines and write_deep_tiles,
  which should be overloaded by any format writer supporting deep images,
  and write_deep_image (implemented in terms of the others).
Document API changes for deep data I/O
Very rudimentary ImageBuf support for deep data.

A DeepData field has been added internally to ImageBuf.  Deep images loaded
as ImageBufs will read directly into there, bypassing the traditional pixel
storage (or ImageCache) used by non-deep ImageBufs.

ImageBuf::Iterator (and ConstIterator) have been modified to be deep-safe.
You can't use the iterator to directly access the deep data, but you can
still use it to iterate over the pixel range and access ib->deepdata()
for the right pixels.

The vast majority of ImageBuf methods don't work properly with deep images.
Really all you can do with it is load it, treat the data as read-only,
and pull out bits of ib->deepdata() as needed.

A small number of ImageBufAlgo functions have been modified to work
properly with deep ImageBuf's: computePixelStats(), compare().
OpenEXR 2.0 deep file support.
TIFF: any compression requested that starts with 'zip' gets zip.
Add basic deep file support to utilities.

The support is very limited.  iinfo and oiiotool can safely load deep images
and print information about them, with -a, -v, --hash, --stats working.
idiff works with deep images.
Almost nothing else is expected to work with deep images at this time.
Update docs
Minor fix to something that broke during merge