Rework build/update/release process

[pg9182]

Goals:

• Support multiple northstar releases at HEAD.
• Support getting northstar from CI artifacts in addition to releases.
• Automate more of the update process, and support doing it before a full release.
• Support selectively updating the image for past releases.
• Proper staging environment (with promotions and rollbacks of specific versions) instead of just the dev build -> approval -> release process.
• Allow more people to approve updates.
• Should not change anything about the built image; it'll still be 100% compatible with what is currently done including the /usr/lib/northstar dir that some people depend on (even though it's technically an unsupported implementation detail).

Tasks:

• Split merge stuff, support configuration for each ns version.
• Decide whether to push all old versions too by default or only when triggered manually (probably the latter)
  • If the latter, write a script to re-tag the latest version to keep the order and recommended install command in gh consistent.
• Maybe split config stuff too.
• Decide whether to make the Dockerfile templated or whether to add a build arg.
• Add northstar version manifest for keeping track of known (to be compatible), supported (whether to support building for it, this will mostly be keeping stuff as long as possible), and updated (whether to allow pushing new images) versions.
  • Decide on a policy (and possibly automation of it) for which versions are going to be updated and supported.
• Implement pipelines
  • Dev build northstar-dedicated-dev (probably all supported versions, or maybe just the latest with a manually triggered one for all supported versions).
  • Staging release northstar-dedicated-stg:1... (either manually triggered or based on tags, either build from scratch or push the corresponding dev build if it's the same).
  • Release northstar-dedicated:1... (promoted from staging) (also look into having this vote-based with more people allowed to vote) (also look into integrating this with l1ghtman's server management bot)
  • Maybe one for opening a PR for the latest NS release.
  • Maybe one for dropping old versions.
• Investigate the possibility of removing package metadata from the layers and/or using buildkit's linked copy to make layers completely independent and deduplicatable.
• Push cache image #20
• Document the update/release process, including steps to test images.
• Add additional repo collaborators.
• Maybe move to the NS org (or a new one) for more granular permissions.
• Add proper issue tags.