Improvements to fast_math functions

 * Improved approximation for erf
 * Add approximate ierf (inverse erf)
 * Improve range reduction for fast_sin/cos/tan when SSE4.1 or higher is enabled
 * Add some more comments on fast_sinpi
Add maketx option to sharpen as we create MIP levels.

The idea is that production sometimes thinks the filtered textures look
a little too blurry and washed out (even though we know that they're
filtered almost exactly right). So with this, we optionally do a
sharpening step (via unsharp_mask) as we create MIP levels. This gooses
the high-frequency detail just a bit.  Example command line:

  maketx input.exr -sharpen 0.5 -filter unsharp-median -o texture.exr

Play with the sharpening amount (I like somewhere between 0.25 and 0.5)
and with whether you use the unsharp-median or (by leaving out the
-filter or setting it to an ordinary name like "lanczos3") whether you
use the usual Gaussian-based unsharp mask

This is all experimental! Use at your own risk.
Fix typo in recent maketx change
CHANGES
Rearrange some fmath templates to avoid some type ambiguities
Definitions of OIIO_PURE_FUNC, OIIO_CONST_FUNC, OIIO_NOTHROW, OIIO_UNUSED
simd.h: additional functionality and fixes

abs, min, max, ceil, floor, floori, xor, shift left and right,
transpose, unary minus, specializations of shuffling for SSE3, fix buggy
int reduce_add, implement float reduce_add, fixed int4(float4)
conversion, bitcasts
Fix TIFF loss of precision when auto-premultiplying unassociated alpha images.

Frédéric Devernay points out in GH issue #960 that we auto-premultiply
unassociated alpha TIFF images BEFORE converting from native data type.
So if the native data is uint8, we do a premultiply from uint8 -> uint8,
thereby losing precision, even if the call ultimately asks us to convert
to the a higher-precision (e.g., float) data type in the caller's buffer.

The root of the evil is that we do the auto-premultiply inside
read_native_scanline (and tile), which operates entirely in native data
type and is unaware of what buffer data type the user has supplied. Ugh.

The solution is:

1. Add a premult() utility function in imageio.h/imageio.cpp (for easy
   reuse elsewhere).

2. Do NOT do the multiply in the 'native' functions.

3. Add TIFFInput::read_scanline(s)/read_tile(s) functions, which call
   the base class version first, and then (if requested) do the
   un-premultiplication. Seems to work! It's a little roundabout, but
   necessary because the base class read_blah functions do not have the
   TIFF-specific knowledge of whether or not the premultiplication is
   desired. Those methods are already virtual and it's always been legal
   to override them on a format-specific basis, though we've never had a
   reason to do so before.
Timer class changes -- more cleanly separate ticks versus seconds.

Many methods that returned seconds now have a second variety that
returns raw ticks. This is helpful because ticks are an integral type
that can be atomically added to a statistic, whereas double (seconds)
values are more of a pain.
fmath: Make ispow2 and round_to_multiple_of_2 info templates
so they work for size_t also.
Also add some unit tests to fmath_test.cpp, including making sure that
these templates works as expected.
Minor timer tweaks - add ticking() method, make unit test check "skips"
Fix compile error due to using SSE 3 _mm_abs_epi32 when compiling for SSE 2.
make_texture buglet: when doing check_nan, didn't wrap ImageBuf reference properly.
Make a TypeDesc::TypeFloat4
simd.h: unary - operator should be const.
Address SSE3 vs SSSE3.

Brecht points out that we set OIIO_SIMD_SSE to 3 when detecting __SSE3__,
but actually, some instructions may require SSSE3. Oy.

My theory is that there are only a few old (only 32 bit?) architectures
that are SSE3 but *not* SSSE3, and that it's no big deal for those oddballs
to get SSE2. So my proposed solution is to set OIIO_SIMD_SSE to 3 when
we see __SSSE3__.
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.