CBOM: add protocol registry schema

[bhess]

Summary

This adds a protocol registry to cryptography-defs, alongside the existing algorithm families and elliptic curves. Protocols are defined per family and version, each with its algorithm composition, so tools can answer questions like "can this protocol version negotiate a post-quantum key exchange?" without every CBOM re-describing the protocol.

The TLS 1.3 entry is illustrative for now; the list will be populated further (TLS 1.2, SSH, IKEv2, ...).

What's added

A new top-level protocols array. Each protocol version carries a composition: a list of functional slots that all apply together.

• role: what the slot does (key-exchange, signature, ...); open string with examples, like variant.primitive.
• selection: how many algorithms of the set are used at runtime: all-of, any-of, or one-of.
• selectedBy: how that choice is made: negotiation, configuration, server-selected, ...
• algorithmSet: algorithm names matching the variant patterns of the algorithm registry, or named bundles {name, algorithms[]} for cipher suites and hybrid key exchange groups.

Example, TLS 1.3 key exchange:

{
  "role": "key-exchange",
  "selection": "one-of",
  "selectedBy": "negotiation",
  "algorithmSet": [
    "x25519",
    { "name": "X25519MLKEM768", "algorithms": ["x25519", "ML-KEM-768"] }
  ]
}

Backwards compatibility

No breaking changes, protocols is optional. protocolFamiliesEnum uses the same tokens as protocolProperties.type, so a BOM references a registry entry via protocolProperties.type plus version.. no new field in the core schema needed.