Add SHA256 and Salt support

[jcjones]

I'm particularly interested in your thoughts on the composition order for the sha256 updates, and whether you think I should go ahead and add support via concatenation for salts to murmurhash. I would note as-is, we would construct a salted murmurhash3 as: mmh3(salt || key, hash_seed) whereas the construction for sha256 is here: sha256(salt || hash_seed || key) and recall hash_seed from the paper is basically the layer number shifted left.

Apologies for the formatting changes in there - Black did that when the arg lists got longer.

[tvdmerwe]

I think the concatenation in the order of (salt||hash_seed||key) is good here. For the sha256 case, hash_seed is not the IV. As it's used to provide a per-layer differentiation for 'key', and is predictable/known, we can treat it as an extension of the 'key'. We want the random salt prepended to inputs that can be known/controlled.

Regarding adding salt support for the murmer case, I don't know if we should add it yet. It might prompt usage in cases where a better hash function should be used.

[tvdmerwe]

A note on hash functions at the first layer (L1): To get k hash functions at L1, we can do this: _sha_256(salt|| hash_no || hashseed || key), where || is concatenation, and where _hashno is a byte value containing which hash we're using. So, for L1 we'd have _hashno increment to the value of k, for all the other layers, it would stay at 1, or 0 depending on where we start (because we only use one hash function from L2 onwards).

I think this only sufficient in the case of a good hash function, which sha_256 is.