DATAFU 46 Hash UDFs return zero-padded strings of uniform length even when leading bits are zero.

The Hash UDFs in 'hex' mode do not return always the same-length string, because
BigInteger.toString() omits leading zeros. So amidst a stream of 94% strings the
same length, 1/16th are shorter by one or more characters, 1/256th by two or
more, and in the unlikely case that an MD5 hash's value was 124 bits of zeros
and 4 bits of ones it would return the one-character-long string 'f'.

This is surprising behavior, and a trap for those practicing the frequent trick
of generating a hash and chopping off just the number of bits you need:

{code}
-- returns one-fifteenth, not one-sixteenth, of the input.
sampled_lines = FILTER(FOREACH lines GENERATE MD5(val) AS digest, val) BY (STARTSWITH(digest, 'f'));
{code}

The attached patch makes the returns a string zero-padded to be (length of hash
/ 4) characters long. It needs a lookup table to know how to format a SHA hash;
all of the [potential SHA-prefixed algorithms in Java 7|http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#MessageDigest]
are covered.

https://issues.apache.org/jira/browse/DATAFU-46

Signed-off-by: Matthew Hayes <matthew.terence.hayes@gmail.com>