Images/CI: add a VERSION to trigger fresh build

What

Introduces a very simple (almost dummy) VERSION file for CI images. The revision number defined in this file should be incremented when we need a fresh build of the CI images even if no relevant file needs to be modified.

Why

CI Images are only re-built if some files are modified (cf. images/ci/inputs).

We may want to force a fresh build, e.g. to use the newest Alpine packages.

How

The VERSION file is minimal: it contains just the name of the images and a revision number.

Incrementing this revision number will trigger a fresh build of the images.

Note that the converse is not true: a fresh build may be triggered by modifying other files listed in images/ci/inputs.

Thus, the revision number will not describe the different number of builds of these CI images. It will only be an indicator of the rebuilds of the CI images occurring without any modification of some relevant file (build scripts, Dockerfile, etc.).

Info we voluntarily omitted from this file:

• alpine version: b/c it could become out of sync with the version used (defined in scripts/version.sh)
• build/modification date: b/t it could be a misleading indication: it could be understood as the date of the last build of the images, which would be incorrect (if files listed in images/ci/inputs are changed, a new build will be triggered).

Manually testing the MR

• Check that the pipeline did rebuild CI images.
  • https://gitlab.com/tezos/tezos/-/jobs/8506552370#L62
  • https://gitlab.com/tezos/tezos/-/jobs/8506474166#L61
• Increment the revision number and either
  • compute locally the hash and check that it has changed
  • launch a CI pipeline after the update and check that new images are built.

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).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR