Add murmur3 32-bit

[vmx]

Also rename the existing murmur to murmur-128.

[Stebalien]

Let's be careful about allocating another single-byte code. Really, we shouldn't have allocated single byte codes to most of these but, IIRC, we did that before we combined the various codec tables.

[vmx]

I took it from the JS Multihash implementation https://github.com/multiformats/js-multihash/blob/443a8ebdd145582f2cac6e708ffe890401d5de08/src/constants.js#L22

[Stebalien]

Damn.

[vmx]

It's even in the multihash RFC draft: https://tools.ietf.org/html/draft-multiformats-multihash-00

[Stebalien]

Addressing @Kubuxu's comment (#45 (comment)) on the previous PR: Murmur3-64 is actually just a truncated murmur3-128. Given how we use these hashes in sharded directories, this doesn't make a difference (we might as well use murmur3-128).

So, the only issues here are:

1. Wasting an additional single byte code. However, given the fact that we've had murmur3-32 defined for a while, I can't really object to this.
2. The fact that murmur3-128 technically has different implementations on 64bit architectures and 32bit architectures: Murmur3-128 output differs between 32-bit and 64-bit implementations by design multihash#85. I believe we have to define these as murmur3-32x32 and murmur3-128x64.

@pgte make sense? Which murmur hash are you using?

[pgte]

@Stebalien the only time I remember needing murmur was when implementing dir sharding here:
https://github.com/ipfs/js-ipfs-unixfs-engine/blob/907a6381b0a3054523b55945ba1d9debb7b60b6d/src/importer/dir-sharded.js#L17
(also please read the comments on line 21).

[Stebalien]

(also please read the comments on line 21).

As far as I can tell, we use as many bytes as we need. Using 8 bytes (64 bits) would mean an 8-deep hamt (which we shouldn't normally have).

However, I've actually just changed the go implementation to support using all 16 bytes of the 128 bit hash (to reduce confusion): ipfs/go-unixfs#53.

[Stebalien]

Merged as this:

1. Matches the multihash table (before it was removed).
2. Matches the RFC.

If we want to free up some of these IDs, we can consider that separately (but probably shouldn't at this point).