CD workflows and GitHub limits

[lmaotrigine]

Another blocker to #2 that I felt should be tracked separately is that currently, docker images are built and pushed on every commit. This will likely exceed the actions/packages storage limits nearing the end of months, causing builds to fail. I say this because as of the time of creating this issue, I've used up about 70% of the quota while being on the Pro plan.

Unfortunately, there isn't a retention policy available out of the box, so even if we decide to only support the X most recent images and prune the rest, it would have to be through a GitHub Action which is subject to both GitHub API rate limits, and security concerns about configuring a legacy PAT (secrets.GITHUB_TOKEN doesn't work because you can't modify its scope, and it, naturally, doesn't have packages:write for another repo).

Actions usage also increases significantly on every tag, because release jobs are triggered for every Rust target that is guaranteed to build, and Windows and macOS runners cost a lot more. However, this is not an issue if we pinky-swear not to cut a release more than, say, twice a month maximum.

I don't want to use Docker Hub because of reasons similar to 5HT2B/heartbeat#9. A possible workaround could be to have CI run only on my own repo, though it could be ambiguous to end users if the source of the container build is different.

If there are other container registries that are more generous with their free offerings, I would be happy to switch.