Manifest: automatic generation of opam packages for releases

Context

This is to go towards being able to automatically release opam packages for Octez (see #1453 (closed)). It builds upon !3366 (merged), which was initially motivated by automatic opam releases. This is based on initial work by @abate .

This MR patches the manifest so that it can take options to generate opam packages for releases (in addition to dev .opam files). It also adds a script that, given a version number and a release tarball URL, creates a branch in a clone of ocaml/opam-repository with the opam packages for an Octez release. Thus, by using this script, one can easily prepare an Opam release for Octez.

Known Issues

In the manifest, all protocol targets are currently todos, which are implemented using external packages. Because they are thus not internal packages from the manifest's point of view, the manifest doesn't know it should mark them with { = version } in dependencies. So this is still a step that has to be done manually until we implement all protocol targets in the manifest.

Manually testing the MR

Check that nothing changes for dev (from the root of the Octez repository):

make -C manifest

(this is already checked by the CI).

Then test the new feature (from the root of the Octez repository):

./scripts/opam-release.sh 12.0 https://gitlab.com/tezos/tezos/-/archive/v11.0/tezos-v11.0.tar.bz2

This creates a clone of ocaml/opam-repository in a new opam-repository folder in your Octez repository, with a branch octez-12.0 which adds Octez 12.0 packages (but using the 11.0 tarball :p).

You can also use an existing ocaml/opam-repository clone by specifying it as an additional parameter for this script.

Automatic Testing?

We maybe could test the script automatically in the CI, but since it depends on an external repository (ocaml/opam-repository), I'm not sure it's a good idea. For now I chose not to add automatic testing.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR