rocq-elpi-json, rocq-elpi-xml: bound dune < 3.24 on the 5 released rows

[JasonGross]

dune 3.24 deleted the coq dune-language extension, so a dune-project
containing (using coq X.Y) no longer parses whatever its own (lang dune ...)
says. opam solves one dune version per switch, so an uncapped recipe in a
closure can select dune >= 3.24 for everything in it.

rocq-elpi-json and rocq-elpi-xml are built out of the same coq-elpi release
tarballs as rocq-elpi — apps/json/ and apps/xml/ of that tree — so the
defect reaches them identically. They were missed by every cap so far because
they are missed by name:

commit / PR	rows capped
34f82e5	rocq-elpi.3.5.0
#3806	rocq-elpi.dev
#3819	the remaining 16 released rocq-elpi / coq-elpi rows

That leaves 18 capped rows at master and these 5 uncapped.

Evidence

The dune-project files were read out of the three release tarballs these 5
rows name in their own url { src: } — v3.3.1, v3.4.0, v3.5.0 — rather
than guessed from opam metadata. All three:

(lang dune 3.13)
(using coq 0.8)

Satisfiability

rocq-elpi, which all 5 rows depend on, already asks for
dune {>= "3.13" & < "3.24"}, and rocq-core.dev / rocq-runtime.dev ask
dune {>= "3.21"}, so 3.21–3.23.x satisfies the whole closure. opam lint
passes on all 5 files.

Deliberately not touched

The coq-elpi rows at 2.5.0 and above are metapackages depending on
rocq-elpi, with no dune dependency and no build; the coq-elpi rows below
2.2.0 have no dune dependency either.

The two extra-dev rows rocq-elpi-json.dev and rocq-elpi-xml.dev carry the
same uncapped dune {>= "3.13"}, but they exist only on #3812 and not at
master, so they are not in scope here and should be capped there.