Correct the bytecode architectures for OCaml 5.1 and OCaml 5.2 (trunk)

[dra27]

This PR fixes two small issues:

• The 5.1.0 beta does not correctly pull in the ocaml-option-bytecode-only package for ppc64
• The 5.2 (trunk) package still has the 5.0 native architecture restrictions, when it no longer needs any

I've extensively tested this (hopefully!) on amd64, ppc64 and s390x. The important details:

• This PR will cause 5.0 bytecode-only switches to rebuild but it does not affect amd64 and arm64 (which will only see a largely no-op rebuild of the ocaml-options-vanilla package)
• This PR does cause all 5.1 switches to rebuild because of the change to the beta package itself (unless you're using opam 2.2 😇)
• Existing 5.2 (i.e. trunk switches) on ppc64, riscv or s390x will be unable to upgrade without manual intervention unless opam 2.2 is being used.

[dra27]

This is a draft for two reasons:

• There are other ocaml-option-* packages which need to be updated for the restored architectures in 5.1 and 5.2
• I think I made a mistake when discussing this with @kit-ty-kate months ago on having ocaml-option-bytecode-only vs base-bytecode-only. Unless I've forgotten the full detail of my counterargument, I think that we were possibly both correct and this should be revised further, but I need to do some more testing.

[dra27]

OK, I've changed the scope of this slightly, in order to allow the two bugs to be fixed more quickly. This revised version now only affects the 5.1 and 5.2 packages (i.e. it's clearly the case that released switches are unaffected). It's also a good deal easier to review as a result 🙂 I have again tested these on s390x and ppc64

• The bytecode-only architectures correctly pull in ocaml-option-bytecode-only (i.e. ppc64 on 5.1 is now re-identified as being bytecode-only) and, importantly, that package cannot be removed.
• For ppc64, s390x and riscv, the 5.2 trunk package now builds the native compiler

The critical fix is that if ocaml-option-bytecode-only is pulled in (i.e. for ppc64 before 5.2 and s390x on 5.1.0~alpha1), then it cannot be removed which means that conflicts: "ocaml-option-bytecode-only" works properly. The part of the fix I've removed is that ocaml-options-vanilla is not working correctly for the 5.2 trunk package (entirely non-urgent, therefore) or for riscv and s390x on 5.1 (relatively non-urgent). The issue is that at present in those configurations it is possible to install ocaml-option-bytecode-only, which shouldn't be permitted (adding ocaml-options-vanilla to the switch invariant is supposed to force the compiler at its default configuration). This is a much lesser concern, as there are plenty of packages which conflict ocaml-option-bytecode-only and no non-compiler packages which depend on it.

Fixing the slight mess with ocaml-options-vanilla will be both disruptive to switches using released compilers and is more complicated to review. I propose therefore to fix that alongside the Windows compilers in the next few weeks.

[avsm]

This looks right to me (and is surprisingly complex!). There are also a number of 32-bit-related options in the configure step which look redundant to me now, but can be fixed in a future PR. Is the idea to get this correct in opam-repository, and then submit a fix to ocaml/ocaml for the trunk metadata to be correct, @dra27? That would help @Octachron with release generation.

[dra27]

I confess I hadn't considered the ocaml-variants.opam file in ocaml/ocaml itself (it's kinda still on the "eventually" spike for getting pinning compiler branches properly sorted... but on the basis that I originally demo'd that in early 2021, it'll probably land sometime next year 😂).

It's not related to the release process, though - I'm fairly sure @Octachron uses the previous packages in opam-repository as the starting point for the following release.

There are also a number of 32-bit-related options in the configure step which look redundant to me now

Yes, indeed! Now that 5.1 has confirmed their removal, those really ought to be simplified. I've added to the list of bits to check along with the Windows parts.

[jmid]

The constraints LGTM, reflecting that

• the native riscv backend was restored with 5.1.0~alpha1
• the native s390x backend was restored with 5.1.0~alpha2 and
• the ppc64 port has been merged into trunk (5.2).