TextureSystem speedups via SIMD instructions

I've been working hard on this for the past few weeks.

This is a big overhaul of the internals of TextureSystem to make as much as possible use SSE (and in future updates, other SIMD instruction sets).  We're seeing 30-60% reduction in time of the texture lookups themselves, depending on the SSE compatibility level, number of channels looked up, whether texture derivatives are requested, etc.  Call it close to a 2x speedup in general. But of course, how much this will translate into speedup of an app using TextureSystem will depend a lot on the original percentage of the runtime of the app that was spent doing the texture math.

This is a first stab, there is more to return to in the future. For example, we have only SSE-optimized texture(), but really not texture3d() or environment(). There's probably even more we can squeeze out of texture() if we try.

To support this, there is a new OpenImageIO/simd.h file containing classes for float4, int4, mask4 (for starters, more might come along later) that get specialized depending on SSE level, and at some point in the future, probably for AVX and Neon and maybe others. This will be exported in the OIIO distro, so feel free to use it in other apps, though beware that it's all in flux now and we do anticipate that things here will change a bit in the coming weeks.

Along the way, I overhauled TextureSystem API -- eliminate nchannels and deriv fields from TextureOpt, in favor of passing them explicitly to the various texture API functions. We removed some long-deprecated API entry points, and filled in some others that were missing (in particular, the multi-point lookups that take a TextureHandle/PerThread rather than a ustring filename). Note that this will require apps that call TextureSystem to modify their source lightly. THIS IS AN INCOMPATIBLE API CHANGE, though a relatively minor one that only affects TextureSystem and no other OIIO APIs at this time.

This is a work in progress, though I think ready to review and, with a bit more testing on production scenes, ready to merge soon. Though I anticipate returning to the SIMD issue and continuing to optimize the parts I didn't get to on this round. Obviously, there are also now lots of ripe optimizations to be utilized for parts of OIIO that are not TextureSystem (the costlier ImageBufAlgo functions, for example).

I'm curious. When you define a type like this to be a union of the simd type and the int[4], assuming the compiler keeps it in a register, what happens when you do m_val[i]? Is it a bit shift? It seems it is not: http://goo.gl/5ftqhu