Padding_len was introduced in 7793c40c07483dd3efed0a27a85922ed5c7f0cee,
but not fixed in the calls hash_message.

Resolves #12

This commit adds support for the parameter sets in the draft version of NIST SP 800-208.

In the public comments to draft version of NIST Special Publication 800-208, ETSI TC CYBER WG QSC identified a multi-target attack against the method of pseudorandom key generation used in this referrence implementation. ETSI TC CYBER WG QSC suggested using the pseudorandom key generation method from SPHINCS+, however, there is still a multi-user attack against that key generation method.

This commit revises the pseudorandom key generation method by using the method from SPINCS+, but adding SEED as an input in order to protect against multi-user attacks. Since prf() only accepts 32-byte inputs, the new key generation method uses a new PRF. The resulting key generation method is sk[i] = prf_keygen(sk_seed, pub_seed || adrs).

The reference implemention of XMSS currently assumes that n bytes of padding is used for the prefix in the functions prf, hash_message, thash_h, and thash_f. While this is the case for all of the parameter sets in RFC 8391, the draft version of NIST Special Publication 800-208 specifies paramter sets in which the amount of padding is different than n.

This commit allows for the padding length for a parameter set to be specified separately from n.

It wrongfully assumed that 2n + 32 = 3n

Since there's a tweak being introduced, this should be reflected
in the name of the functions.

Previous code allocated an array on the stack of mlen bytes, but
it should be possible to also sign heap-space messages. By relying
on the fact that sm and m fit the message + signature, we move
the message so that 4*n bytes of prefix can be added.

The current code results in the same output regardless of endianness.
Verified using a QEMU VM to emulate MIPS.

Using global defines for parameters (as seems to be typical in
academic crypto code) does not play nice with multithreading at all.

This also performs numerous consistency fixes

Versions are incompatible due to different address formats and differing message compression!