picoquic: SNI-based multi-cert selection (tls.fizz.cert_dir parity)

[michalhosna]

Follow-up to #45. The fizz-based listeners (mvfst, proxygen_qmux) gained SNI multi-cert support via tls.fizz.cert_dir; picoquic listeners reject the block at config validation because picoquic cannot select a cert per SNI today:

• Every server connection shares the single master TLS context (picoquic_tlscontext_create uses quic->tls_master_ctx).
• ptls_context_t.on_client_hello is hardwired to picoquic's internal callback; the only app-pluggable part is ALPN selection. The function even carries a TODO: check the SNI in case several are supported.
• All public cert APIs (picoquic_set_tls_certificate_chain, picoquic_refresh_tls_certificate, ...) are quic-context-wide. SNI is readable only after the fact (picoquic_tls_get_sni).
• picotls itself supports per-connection context swap in on_client_hello (ptls_set_context), picoquic just doesn't surface it. The private headers needed to hack around this (picoquic_internal.h, picotls.h) are not installed with the moxygen release artifact.

Upstream path (in order):

1. openmoq/picoquic: expose an app-level client-hello hook (or a built-in SNI→cert table). Most machinery exists (picoquic_clone_ptls_template, refcounted master-ctx swap in picoquic_refresh_tls_certificate); est. ~100-200 lines in tls_api.c + picoquic.h.
2. moxygen: ~5-line exposure (getter for picoquic_quic_t* or a virtual onQuicContextCreated() on MoQPicoServerBase); quic_ is already a protected member.
3. moxygen release + submodule bump, then moqx wires tls.fizz.cert_dir for quic_stack: picoquic and drops the validation rejection.