Refactor ALPN "string" management

We currently have 2 (3?) ways of configuring the ALPN strings:

1. Via the ports configuration in records.config
2. Via sni.yaml (H2 can be disabled)
3. Via plugin APIs (I think ?)

This gets complicated, because the APIs around SSLNextProtocolSet, and cloning, adding and removing endpoints is expensive (lots of memory allocations). The code currently uses global "override" map for each accept port, to hold sni.yaml configurable versions of each ALPN mapping.

Bryan suggests maybe switching the internals to have some sort of bit-map / field for the protocol set members, rather than the strings. This gets a little complicated, since I believe the APIs here are generic and can support more than just the protocols defined for the ports specification. However, it would allow us to manipulate the bitfields, and have predefined SSLNextProtocolSet()'s for all possible versions.

This will also only get worse once we introduce H3 / QUIC, and possibly other protocols, and would need to be able to configure this via sni.yaml.

No source files, tests, or entry points are named. Start by tracing the ALPN configuration through records.config, sni.yaml, and the SSLNextProtocolSet and plugin APIs mentioned in the issue. Done means the configuration paths and future H3/QUIC support use a less allocation-heavy internal representation without losing the generic API behavior.

Written by the indexing model from the issue text.