Move lts-23 and lts-24 to crypton 2, and quic with them

[kazu-yamamoto]

quic 0.3.14 moved to crypton 2, and every snapshot here holds crypton 1, so
quic has been held at 0.3.2. That is what keeps warp-quic from using
anything newer.

lts-23 and lts-24 are one step away from crypton 2 -- they already carry the
modern tls and crypton-x509 packages -- so only the versions move:

	before	after
crypton	1.1.3	2.1.7
crypton-x509	1.9.1	1.9.2
crypton-x509-validation	1.9.0	1.9.1
tls	2.4.3	2.4.8
hpke	0.1.0	0.2.1
quic	0.3.2	0.3.15

The revisions

This looked impossible at first, because stack kept answering

* crypton must match >=1.1.0 && <1.2, but crypton-2.1.7 is in the Stack configuration
  The above is/are needed due to warp-quic-0.0.4 -> crypto-token-0.2.0

while the same package on Hackage says crypton >=1.1.0 && <2.2.
crypto-token-0.2.0 and crypton-x509-store-1.9.0 say < 1.2 as uploaded and
< 2.2 as revised, and the lock files pin the revision as well as the version,
so stack went on reading the bounds those packages had on the day they were
released. They are asked for by revision here, which is also what says why
these three and not the rest:

  - crypto-token-0.2.0@rev:2
  - crypton-x509-store-1.9.0@rev:2
  - crypton-x509-validation-1.9.1@rev:3

What is not here

lts-20, lts-21 and lts-22 stay where they are. They hold crypton 1.0.4, tls
2.1.11, http3 0.1.2 and quic 0.2.21, which is a step of its own and not this
one. stack-nightly.yaml pins none of this and follows the snapshot.

Checked

Built rather than only resolved, with stack build warp-quic warp-tls against
both stack.yaml (GHC 9.10) and stack-lts-23.yaml (GHC 9.8) -- those two
packages being where tls and crypton are actually reached. Both reach
crypton-2.1.7, tls-2.4.8, quic-0.3.15 and hpke-0.2.1.

🤖 Generated with Claude Code

[Vlix]

If it builds, it works.