Fix typo in float4::iota
ImageCache: Zero out the SIMD padding in tile allocations!!!

The texture system tries to use SIMD (SSE) ops. It wants work on four
floats at a time. If there aren't four channels, that's ok, because
we'll zero out "past the end" channels by multiplying with a float mask
that will be 0.  We also pad the end of the allocation for a tile, so if
we retrieve four values (for a texture with < 4 channels) from the last
pixel in the tile, we don't want to run off the end of the allocation
and segfault.

OK, but if it turns out that this padded but uninitialized memory past
the last pixel of the tile happens to have the bit pattern that
corresponds to NaN, then even though it will get multiplied by a mask
such as (1.0, 1.0, 1.0, 0.0), 0*NaN = NaN, *not* 0! (For any non-NaN
value, the float multiply mask trick would work fine.) So this was
allowing NaNs to creap into the texture results. Oops.

The solution is really simple, which is just to use memset to make sure
the padding at the end of the tile allocation is filled with zero
values.
oiiotool -help should say if there is no OCIO support.
Python read_scanlines did not honor channel subset, leading to chaos.
Python - make all IBA functions release the GIL for their expensive part.

The notorious GIL (global interpreter lock) prevents other Python threads
from executing while our functions are holding the lock.

We use a ScopedGilRelease found in many places on the web. Its purpose is
to release the GIL before expensive work, then properly re-acquire it again
when it exists scope. This allows other Python threads to advance while we
are doing the meat of our work.

In many case, this meant writing a wrapper (to scope the GIL business)
where before we did not need a wrapper.