Fix #268, issue with right shift in fast huf decoder

Technically, doing a logical right shift by the number of bits (or more)
of a number is undefined behaviour. gcc / x86 seems to do (v >>
(shift%bits)), meaning that a right shift of 64 would end up as a right
shift of 0 on a uint64_t value. However, other platforms may shift by
the full number of bits and produce and output 0, not the input. Instead
of leaving this ambiguity, force the 0th value to be manually unrolled /
extracted and to do what was there (and validated by test) as an
undefined behaviour as a more explicit operation.

Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>

OpenEXR/IlmImf/ImfFastHuf.cpp

@@ -373,7 +373,8 @@ FastHufDecoder::buildTables (Int64 *base, Int64 *offset)
     // as 'offset', when using the left justified base table.
     //
 
-    for (int i = 0; i <= MAX_CODE_LEN; ++i)
+	_ljOffset[0] = offset[0] - _ljBase[0];
+    for (int i = 1; i <= MAX_CODE_LEN; ++i)
         _ljOffset[i] = offset[i] - (_ljBase[i] >> (64 - i));
 
     //