Add Nuke txReader/txWriter plugin sources and build files

Add source and build code for Nuke plugins to read and write .tx files using OIIO. These were originally written at Luma against a much older version of OIIO, but have been updated to work with the current API.

txReader
-----------
- Reads a single mip level, up-sampling it to the resolution of the 0'th mip level.
- Supports up to 4 channels
- Reads common TIFF and OIIO metadata

**TODO**
- [ ] Support more than 4 channels (need to implement channel name mapping, or just treat all channels after RGBA as single-channel layers)
- [ ] Use OIIO to validate files, rather than TIFF byte testing
- [ ] Implement planar Reader API in Nuke 8?
- [ ] Handle mip orientations properly (if desired)

txWriter
---------
- Writes up to 4 channels
- Provides control over a subset of the `maketx` options
    - Bit depth
    - Filter
    - File "presets" (OIIO, prman)
    - Tile size (unless using preset)
    - Planar configuration (unless using preset)
    - "Fix NaN" mode
    - "Check NaN" option (currently disabled)
    - Verbose/stats output

**TODO**
- [ ] Re-enable "checknan" control after testing against OIIO patch #967 
- [ ] Enable support for more than 4 output channels
    - Code for this is already in place, but OIIO does not seem to respect the custom channel names
- [ ] Explore more efficient methods of populating source ImageBuf (e.g. using the Iterator interface)
That's difficult to answer without knowing how the Iop::sample() calls and the Planar stuff interact - I've not had a chance to work with it yet.  The issue is that any node between a shader and the Read with the texture path which doesn't implement the sample() methods will accessing the default Iop::sample() methods which perform multiline filtering of the input lines using an Interest or Tile which ultimately calls the engine() method in the Reader.

Perhaps the Foundry rewrote the Iop::sample() calls to perform tiled operations more efficiently, but I can't see that getting around nodes that only have engine() implementations killing texture read performance.  Grepping for 'sample(' in the headers of 8.0v5 only show Iop & Transform with implementations, so I doubt they've done anything new there.
I think they're banking on the on-the-fly mipmapping in Nuke9 helping out - but that's pretty hefty memory requirements for multiple 16k textures and a hefty startup cost.

So...I still think it's better to have a dedicated 'ReadTexture' node that implements the sample() call, or embed texture readers in custom texture source knobs on your own shaders.  I've done both successfully.