Refactor sub-actions

[SuperQ]

Currently the way we use promci is that we use a top-level action that clones the promci repo so that each action can be used.

This requires manual bumping, which is additional toil and annoyance.

Let's refactor things so that we can call actions directly. For example:

publish_main:
  steps:
    - uses: prometheus/promci/publish_main@<foo>

This will require splitting out some actions to separate repos to avoid the recursive calls.

• prometheus/promci/actions/setup_environment -> prometheus/promci-setup/environment
• prometheus/promci/actions/save_artifacts -> prometheus/promci-setup/save_artifacts
• prometheus/promci/actions/restore_artifacts -> prometheus/promci-setup/restore_artifacts
• prometheus/promci/actions/publish_images -> `prometheus/promci-images
• prometheus/promci/actions/publish_release_images -> prometheus/promci-images

We can also inline two actions that are fairly simple:
* save_artifacts
* restore_artifacts

[SuperQ]

It turns out we still need the save/restore actions for direct CI use.

[roidelapluie]

check_proto could live in Prometheus.

For the rest, I propose:

Repo	Actions	Responsibility
promci-setup	setup_environment	Go/npm/Docker environment setup
promci-build	build	Cross-platform builds via promu
promci-artefacts	save_artifacts, restore_artifacts	Artifact persistence between jobs
promci-images	publish_images, publish_release_images	Low-level Docker image publishing
promci-publish	publish_main, publish_release	Orchestrate full publish pipelines

[SuperQ]

prometheus/promci-artifacts#1

[SuperQ]

Second repo setup: prometheus/promci-images#1

[SuperQ]

Setup repo: prometheus/promci-setup#1

[SuperQ]

With the first 3 refactors, I found that we broke the dependency cycle enough that we can just rework the build/publish actions without needing new repos for them.