Siloing candidate images

[innovaker]

Following on from #12, I think we should consider creating a dedicated namespace for candidate images to supersede zmkfirmwaredependabot.

Naming suggestions:

• zmkfirmware-candidates
• zmkfirmware-staging
• zmkfirmware-testing

The idea being that every candidate image (those tagged only with their associated GitHub SHA) - including dependabot - are pushed to this namespace, and only released images are pushed to the zmkfirmware namespace.

Potential benefits:

• less junk in the zmkfirmware namespace
• easier discovery and navigation of released images
• reduces chance of users downloading experimental or untested candidates
• easier maintainence (cleaning out redundant images)
• possibly more secure?

Depending on the approach, it might require two sets of credentials to be provided as secrets - one for each namespace.

Care must also be taken around the caching so as to not inadvertantly break the inherent nuances of the design.

[innovaker]

jobs.<job_id>.environment may also prove useful depending on the approach.

[innovaker]

An alternative to dedicated namespaces is to add suffixes to the repository names.
i.e.

• zmk-build-arm
• zmk-build-arm-xxxxxxxxxx
• zmk-dev-arm
• zmk-dev-arm-xxxxxxxxxx

etc.