Add Multiplatform Nightly musl Images

[SeanTAllen]

This introduces a number of changes for our container image building.

It introduces the eventual deprecation of latest as a tag. At the moment, our use of latest is misleading. That is supposed to be "most recent" but we don't use it as such. For us it is "most recently nightly".

This commit will be the start of us having "nightly" images that are explicitly a nightly build. Additionally, our tags will have a qualifier for the libc version. In the case of this musl image the tag would be "musl-nightly". When we do the same for GNU libc, the tag would be "gnu-nightly".

This same name scheme will end up being carried over to releases: "musl-release" and "gnu-release" as well as "by version" tags "musl-0.60.0" and "gnu-0.60.0". The older tags will be dropped as this rolls out.

We can if we want then start using a variation on latest with "musl-latest" and "gnu-latest" should we want, or for ponyc images we can ditch the entire concept of "latest" as "nightly" and "release" versions will always be for a given library the latest nightly and latest release.

In addition the tag name changes, this also is our first multiplatform image. The build process for this is as simple as I could make it. We have a new workflow for building the nightly image. It is set to have a concurrency of 1 so, as events arrive from Cloudsmith, we will build a new version of the image with whatever is the latest nightly arm64 and latest nightly am64 version of ponyc that is available in Cloudsmith.

This means that as we upload to Cloudsmith each night we will create the image twice. If the arm64 synchronized message arrives first and then the amd64 one we will have the following happen:

• arm64 message arrives
• Build a new "nightly image" with today's arm64 and yesterday's amd64
• amd64 message arrives
• Build a new "nightly image" with today's arm64 and today's arm64

The same pattern would be applied to releases.

At the time the message arrives, the image will be built using the most recent version of ponyc for each platform that is available. This has a couple nice qualities to it:

• If one failed to build, we still make the one that succeeded available.
• It makes our configuration relatively simple

Without this "cross over", we would need to wait for each message to have arrived and then build the final image. That is some tricky yaml that we should want to avoid doing if possible.