Use released tags for finalised versions of opam

[dra27]

The base images at the moment build the tips of branches from ocaml/opam which aren't always release tags. This is brilliant during an opam dev cycle, but a little surprising outside of one as it can cause opam to say it's a development version when a user of the image might be expecting it to be a release version.

We should switch /usr/bin/opam-2.0 and /usr/bin/opam-2.1 to build the latest release tag for that series (preferably by querying the tags from the GH API and selecting the latest!).

When 2.2 alpha is released and we want to add /usr/bin/opam-2.2, that should certainly be building the tip.

There is a potential problem with developer builds: hard upgrades are a forced interactive prompt:

FROM ocaml/opam:debian-10-opam
ENV OPAMYES="1" OPAMCONFIRMLEVEL="unsafe-yes" OPAMERRLOGLEN="0" OPAMPRECISETRACKING="1"
RUN sudo curl -sLo /usr/bin/opam-2.1.0-beta4 https://github.com/ocaml/opam/releases/download/2.1.0-beta4/opam-2.1.0-beta4-x86_64-linux
RUN sudo chmod +x /usr/bin/opam-2.1.0-beta4
RUN /usr/bin/opam-2.1.0-beta4 update
RUN /usr/bin/opam-2.1 update

At the moment there's no issue because 2.0 -> 2.1 is not a hard upgrade, but we should ensure that the dev builds in the containers either have this mode disabled (by tricking opam into thinking it's not a development build) or by ensuring that there's an explicit option in opam's configure system to disable it. The forced interactive prompt is there to protect developers' systems, as a hard upgrade re-inits.

• Base images opam-2.0 and opam-2.1 correspond to releases
• Development builds are never forced to be interactive