fix: LMOTS pattern, add HSS variant (LMS family)

[Mehrn0ush]

Hi,
LMOTS had a treeHeight parameter it shouldn't — LM-OTS doesn't use a Merkle tree, so there's no height involved. Swapped it for the Winternitz parameter w, which is what actually distinguishes the RFC's parameter sets (LMOTS_SHA256_N32_W1/W2/W4/W8).

Also added HSS, which was missing entirely. It's just the multi-level LMS construction, parameterized by number of levels (L), so the pattern is intentionally minimal — no hash/M/H, since those come from whichever LMS parameter set each level uses.

LMS itself was already correct.

"LMOTS[_{hashAlgorithm}][_N{bytesPerNode}][_W{winternitzParameter}]"
"HSS[_L{levels}]"

One question — LMOTS still reuses {bytesPerNode} for its N parameter, but RFC 8554 calls this n — the LM-OTS hash output length, not a node value (LM-OTS has no tree nodes). Should this be renamed to something like {hashOutputLength} on LMOTS, keeping {bytesPerNode} only on LMS where it's accurate? Didn't want to bundle a naming change into this fix, so leaving it open — happy to push a follow-up if there's agreement either way.

Closes #1028.

[jvdsn]

Also added HSS, which was missing entirely. It's just the multi-level LMS construction, parameterized by number of levels (L), so the pattern is intentionally minimal — no hash/M/H, since those come from whichever LMS parameter set each level uses.

Would there be any way to express that? Dependencies?

Note for reviewers, RFC 8554 explicitly allows a lot of flexibility:

We specifically allow different LMS levels to use different parameter
sets. For example, the 0-th LMS public key (the root) may use the
LMS_SHA256_M32_H15 parameter set, while the 1-th public key may use
LMS_SHA256_M32_H10.

[Mehrn0ush]

Hi,
@jvdsn thank you for reviewing this PR.
In this schema, variant only has pattern/primitive/standard, no dependency field, so there's no structural way to express this today. XMSSMT handles its multi-tree case by encoding {h}/{d} directly in the pattern string, but that only works because XMSS-MT levels share one parameter set. HSS can't use the same trick since RFC 8554 allows each level to pick an independent LMS parameter set. Left HSS[_L{levels}] as-is for now — a real fix would need a schema change to support per-level composition, which is bigger than this PR. (For what it's worth, I also checked the v2 cryptography schema — it moves to a free-text parameterSetIdentifier per algorithm instance rather than family-level patterns, and doesn't add a composition mechanism either, so this looks like a genuine open gap rather than something already solved elsewhere.)
Happy to adjust further if maintainers have thoughts on this — let me know if any additional changes are needed here.