CI: remove [doc] stage

What

• Removes [doc] stage.
• Its jobs are dispatched to other stages.
• Some jobs are renamed to be prefixed by documentation.

Why

• Job stages should not refer to the product it is related to but should describe what the job does (e.g. building, testing, deploying).

• Fewer jobs simplify pipelines and make them easier to visualise and understand.

How

• Removes [doc] from the registered stages,
• Dispatches job previous in the [doc] stages to more relevant stages: [build] for doc jobs that build the documentation, [publishing] for the job that publishes it.

Manually testing the MR

• make -C ci check
• Have a look at the test pipelines:
  • before_merging: https://gitlab.com/tezos/tezos/-/pipelines/1861749442
  • master_branch: https://gitlab.com/tezos/tezos/-/pipelines/1861749663
  • schedule_extended_test: https://gitlab.com/tezos/tezos/-/pipelines/1861750163
  • schedule_documentation: https://gitlab.com/tezos/tezos/-/pipelines/1861751491

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