CI: streamline publishing related stages

What

Follow-up of !18254 (merged).

Streamlines stages that contain "publish" in their name.

1. Renames [publishing] into [publish] stage.
2. Merge [publish_release, publish_release_gitlab, publish_package_gitlab] into [publish]
3. Merge [prepare_release] into [publish]
4. Merge [publishing_tests] into [test] (Will be done later as it breaks the debian/rpm pipelines cf. https://gitlab.com/tezos/tezos/-/pipelines/1862295819)

Why

We need only one stage for jobs that publish some artifact.

1. To be consistent with other stage names: build, test, etc.
2. Jobs of these stages all publish assets (static binaries, release pages, etc.)
3. [prepare_release] contain only the [docker:merge_manifests] job that creates and pushes manifests for a multi-arch version of the Octez Docker images.
4. [publishing_tests] jobs test functional properties (install, upgrage) of Debian/rpm packages and checks other properties (lintian).

How

Self-evident.

• Removes the registered stages.
• Change the jobs stage.
• make -C ci

Manually testing the MR

• make -C ci check

• octez_release_tag_test-like pipelines are probably those which are most affected by the changes as they lose 3 stages. (For most other pipelines, it's just a renaming of a publishing related stage.) Compare

  • a recent release pipeline (octez-v22.0) https://gitlab.com/tezos/tezos/-/pipelines/1755725146
  • with this one showing the effect of this MR https://gitlab.com/nomadic-labs/tezos/-/pipelines/1862143129

Next steps

In the end, we should only have a few core stages: start, build, test, publish (and perhaps [images] at first). We are planning to progressively remove all other stages and dispatch their jobs into these core stages.

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