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
Merge pull request #437 from lgritz/lg-deep

Deep images, OpenEXR 2.0
Clean up library symbol visibility issues.
(based on recent similar OSL symbol visibility fixes)

* On gcc-based systems, use __attribute__((visibility("hidden|default")))
  (in export.h) to clearly mark which symbols must be visible as part of
  the public API (or that must be found by dlsym() in order for LLVM to
  correctly generate code to call them from shaders), versus symbols
  used only internally to the library that don't need to be visible to
  apps linking OSL libraries.  Note that Windows already did this for DLLs.

* For Unix-like systems, if the CMake variable HIDE_SYMBOLS is on (or
  'make HIDE_SYMBOLS=1'), then use -fvisibility=hidden on the compile & link
  lines to control symbol visibility so that the default is to hide symbols
  not marked as part of the public APIs.  (Note: Windows does this by
  default.)  Even if HIDE_SYBOLS=1, the symbols are not hidden for DEBUG
  builds, so that all the symbols are available.

* On Linux, also use linker option --version-script and a custom
  version-script for libOpenImageIO.so in order to force the symbols of
  our dependencies to also remain hidden outside the OIIO library.  This
  is extremely helpful to apps that want to embed OIIO but also embed
  our dependencies separately for other reasons (and not necessarily the
  same versions) -- this makes sure the symbols don't crash when the
  program runs, leading to strange crashes.
Change to newer OIIO_API and OIIO_EXPORT macros
Merge pull request #442 from lgritz/lg-symbols

Hide library symbols, better-named export macros
Fix up error detection and reporting in maketx.
Addresses problems reported by Michel Lerenard.