feat: verify ML-DSA server certificates (requires Go 1.27)

[nihiloid]

Why this needs Go 1.27, and why that breaks consumers

This pull request raises the minimum Go version from 1.24 to 1.27. A consumer on Go
1.24, 1.25, or 1.26 cannot build the library after this change. The reasons come
first, because this cost must be clear before the feature.

1. ML-DSA signature verification needs crypto/mldsa. That package starts with Go
   1.27. No earlier release holds it.
2. Certificate chain verification needs ML-DSA in crypto/x509. Go 1.27 adds the
   MLDSA public key algorithm, the MLDSA44, MLDSA65, and MLDSA87 signature
   algorithms, and the PKIX and PKCS#8 key formats of RFC 9881. See
   golang/go#78888, accepted with the
   milestone Go1.27, and golang/go#77626.
3. This repository does not hold a copy of crypto/x509. All 8 call sites import
   the standard library package. Thus the certificate half of ML-DSA is impossible on an
   older toolchain, with or without a third-party ML-DSA library. A Go 1.24 build gives
   UnknownSignatureAlgorithm for an ML-DSA certificate, and the chain does not verify.

Two alternatives keep Go 1.24, and this pull request rejects both:

Alternative	Why not
github.com/cloudflare/circl for the primitive	Point 3 stays true: crypto/x509 still cannot parse or verify an ML-DSA chain. It also adds a third-party dependency and moves the code away from the upstream crypto/mldsa API, thus each later rebase costs more.
Build tags, crypto/mldsa above Go 1.27 and CIRCL below	2 implementations of the same verification path to keep the same, a double test matrix, and point 3 still holds for the older half.

Why now. The Chrome 150 profiles already send the ML-DSA codepoints 0x0904, 0x0905,
and 0x0906 in signature_algorithms (u_parrots.go). The library could not honor them.
A server that selected one ended the handshake with an alert. This change closes that
gap between what the profile claims and what the library can do.

InsecureSkipVerify is not a workaround

Without this pull request, a client cannot complete an ML-DSA handshake at any trust
setting. InsecureSkipVerify does not help. A test on the commit a335c30, with Go
1.24, InsecureSkipVerify: true, and the profile HelloChrome_150_PSK, gives this
result on both ports:

test.openquantumsafe.org:6184 FAILED: tls: server's certificate contains an unsupported type of public key: <nil>
test.openquantumsafe.org:6197 FAILED: tls: server's certificate contains an unsupported type of public key: <nil>

InsecureSkipVerify removes the chain verification only, which is the call
certs[0].Verify(opts). The switch on the public key type at handshake_client.go:1221
runs after it, and always. That switch accepts RSA, ECDSA, and Ed25519 only.

The value <nil> in the message shows a second part of the same problem. Go 1.24
crypto/x509 reads the ML-DSA certificate without an error, but gives no public key,
because it does not know the algorithm OID.

2 independent gates stop the handshake, and a change of the trust settings opens
neither:

Gate	Location	Result
The type of the public key of the certificate	handshake_client.go:1221	The error above.
The accept list of signature schemes	handshake_client_tls13.go:853	tls: certificate used with invalid signature algorithm, because supportedSignatureAlgorithms holds no ML-DSA scheme.

Thus this work is not only about trust in a chain. The library cannot speak the protocol
with an ML-DSA server until it holds these changes.

Prerequisite: #413, the Chrome 150 profiles

Merge #413 first. This work needs HelloChrome_150 and HelloChrome_150_PSK, which
#413 adds. The base of this pull request is master, because a pull request cannot use
a branch of a fork as its base. Thus the diff below also holds the 2 commits of #413.
After #413 merges, only the 10 commits of this work stay.

The dependency is not a question of order alone. It holds for 3 reasons.

1. The ML-DSA codepoints live in the Chrome 150 specification. The 3 raw values
   0x0904, 0x0905, and 0x0906 are in the profiles of Add Chrome 150 and Safari 18.5 profiles, with JA4 tests #413. This pull request gives
   them the names MLDSA44, MLDSA65, and MLDSA87.
2. Every ML-DSA test uses HelloChrome_150_PSK. The client does not advertise
   ML-DSA in a default ClientHello, as the section "What this does not change" explains.
   Only a profile that holds the codepoints in its own signature_algorithms extension
   offers them.
3. Without such a profile the feature has no user. The accept list alone changes
   nothing that a client can reach, because no hello in the library would offer ML-DSA.

Note that #404 adds Chrome 150 profiles as well, from a different author. If #404 merges
in place of #413, this work needs a rebase. The changes here stay correct, because they
need only a profile that holds the 3 ML-DSA codepoints.

What this adds

• MLDSA44, MLDSA65, and MLDSA87 of type SignatureScheme, with the same names and
  values as Go 1.27 crypto/tls.
• An ML-DSA case in verifyHandshakeSignature, and the map from the 3 schemes to no
  pre-hash in typeAndHashFromSignatureScheme.
• An ML-DSA case in processCertsFromServer, which rejects ML-DSA below TLS 1.3.
• clientSupportedSignatureAlgorithms, which the client uses to accept the
  CertificateVerify message of a server.
• Names in place of the raw codepoints in the Chrome 150 profiles. The bytes on the wire
  do not change, which the JA4 tests show.

What this does not change

• The bytes of a default ClientHello. The 2 call sites that build the hello keep
  supportedSignatureAlgorithms. Thus the fingerprint of HelloGolang stays the same.
  Only a profile that holds the ML-DSA codepoints in its own extension offers them.
  Go 1.27 crypto/tls advertises ML-DSA in its default hello. This library does not,
  because a change of the default fingerprint costs more here than the match gives.
• The server role. The 3 server call sites of supportedSignatureAlgorithms keep
  that function. A uTLS server does not advertise the ML-DSA codepoints, and rejects an
  ML-DSA client certificate. defaults.go holds no ML-DSA. 3 tests hold this line.
• ML-DSA client certificates. They stay unsupported.

The 64 reference tests

The Go version bump alone breaks 64 tests that replay a recorded transcript from
testdata. Go 1.27 gives the io.Reader of the caller to rand.CustomReader in
ecdh.GenerateKey, which returns the system source. Thus each run makes a different
ephemeral key, and no record can match.

The repair is 1 line: a go:debug cryptocustomrand=1 directive in
u_cryptocustomrand_test.go. That option makes rand.CustomReader give the reader of
the caller through.

Condition	Failures
Go 1.27	64
Go 1.27 with cryptocustomrand=1	0

No transcript needs a new record, and the tests need no OpenSSL.

Test evidence

• Unit tests for the codepoints, the scheme map, and a sign and verify cycle.

• 3 server regression tests, which fail if ML-DSA enters the shared list.

• An end-to-end test in 1 process: a standard library TLS 1.3 server with a
  generated ML-DSA certificate, and a uTLS client with HelloChrome_150_PSK.

• Network tests against the Open Quantum Safe test server, which is NGINX with OpenSSL
  3.5 or later. They skip with go test -short. All 3 parameter sets pass:

  --- PASS: TestChrome150PSKConnectsToMLDSAServer/ML-DSA-44
  --- PASS: TestChrome150PSKConnectsToMLDSAServer/ML-DSA-65
  --- PASS: TestChrome150PSKConnectsToMLDSAServer/ML-DSA-87
  

  Each connection selects X25519MLKEM768 for the key exchange. Thus 1 connection covers
  post-quantum key exchange and post-quantum authentication.

• The full test suite passes: ok github.com/refraction-networking/utls.