Support for HTTP/3 (QUIC)

This would solve...

undici supports HTTP/1.1 and HTTP/2 but not HTTP/3. HTTP/3 over QUIC avoids transport-level head-of-line blocking, supports connection migration on changing networks, and brings undici to parity with browsers and curl. Without it, undici cannot speak h3 to origins or CDNs that offer it.

The implementation should look like...

An HTTP/3 client built on Node's node:quic (which provides HTTP/3 via nghttp3). node:quic is only available when Node runs with --experimental-quic, so undici should feature-detect it at runtime and use HTTP/3 (advertise h3 in ALPN) when it is present, falling back to HTTP/2 / HTTP/1.1 otherwise — mirroring how undici already feature-detects node:sqlite in lib/util/runtime-features.js. Implement it as a client parallel to the h2 client (e.g. lib/dispatcher/client-h3.js alongside client-h2.js), reusing the dispatcher and Request/handler lifecycle. Behaviours already handled for h2 carry over — for example the Expect: 100-continue early-final-response handling from #5470.

I have also considered...

N/A

Additional context

HTTP/3 is RFC 9114; QUIC is RFC 9000. Node provides node:quic with HTTP/3 support behind --experimental-quic (currently Stability 1.0); undici would use it when that flag is enabled and follow its stabilization. Prior discussion: #305 (a 2020 HTTP/1-over-QUIC experiment, closed in 2021).

Start by reading the h2 client alongside lib/util/runtime-features.js, then inspect Node's experimental node:quic entry point. Done means an h3 client can advertise h3 when QUIC is available, reuse the dispatcher and Request/handler lifecycle, and fall back to HTTP/2 or HTTP/1.1 when it is not.