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.

[mozkeeler]

Looks good in general - I left a few comments.

[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 || hash_seed || key), where || is concatenation, and where hash_no is a byte value containing which hash we're using. So, for L1 we'd have hash_no 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.