It's not used outside xmss_commons

This behavior was completely unpredictable from the function name,
in particular when comparing it to other set_*_addr functions.

It wrongfully assumed that 2n + 32 = 3n

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

This is relevant because of the enormous difference in signing
speed between the regular and BDS-traversal-based xmss core.

This ensures that xmss_core and xmss_core_fast offer the same API.
Note that xmss_core_fast still needs a major refactor, and this
wrapper is not exactly very clean. There is a considerable chance
this refactor will change the format of the state in the secret key.

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.

This allows different backends to store additional state information
in the secret key while the rest of the codebase remains agnostic.

In particular, this prepares for a common xmss_core.h API for both
the standard and the BDS-traversal-based implementations.

This removes a lot of code duplication.

This produced repeated indices when reaching 2^32 signatures.
This was introduced in 9b35b00d98
with the re-introduction of runtime parameters. Compile-time parameters
did not contain this error.

As a result, performs various refactors that also impact the verification
function, since cleaner signing functions exposed more overlap.

This greatly reduces the memory comsumption of the auth path
computation, since it now also uses treehash. It prevents
duplicate code by re-using the treehash function.

A downside is that it does also pick out the authentication path
during key generation (while it is not used), but this cost is
negligible.

This is the same fix as 998137622a

Wrote this to find what turned out to be an external error when
using the interfacing programs, but felt like it might as well be added.

Under the same key and message, the signature is expected to be identical.
However, as the index changes, this case will not happen in real use.

This caused secret key files to become close to MAXINT bytes, as
the unsigned int that is the private key size would be subtracted
from MAXINT when its negative was used as offset.

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

The variable sm should contain the signature and the message,
not the message and the signature (i.e. the order is crucial).