Switch from CircleCI runners to Github actions

[almet]

This is still pretty much a WIP. I'm pushing it here mainly to see how the CI is reacting.

Fixes #674

[almet]

Here are the changes I did in this PR, which is up for discussion:

"dev" environments (dangerzone.rocks/build/distro-version) are now built daily, and pushed to the github container registry, so that the CI can reuse them during the day, without having to build them.

I'm currently using the ghcr, but I'm wondering if using a cache instead would be more beneficial, because we could invalidate the cache more easily, and rebuild the dev images on the fly if needed.

The dangerzone container image is also built daily, cached and uploaded to the ghcr.

"end user" (dangerzone.rocks/distro-version) images are currently not uploaded because they require a .deb or .rpm to be built, which is part of the CI pipeline.

While doing these changes, the dangerzone.rocks prefix shown to be cumbersome, as it is taking the place of the container registry. As a result, I now changed this prefix to dangerzone instead, only for the "dev" and "end-user" images.

We might want to follow the same lead for the main container image dangerzone.rocks/dangerzone.

With these changes, the CI is now taking ~9mn to complete all the tests! 🐎

[almet]

I'm currently using the ghcr for the dev images, but I'm leaning towards getting it (almost) out of the picture, as I'm not sure it makes more sense than using a cache with podman save / podman load -i.

This last option will make it easier to invalidate the cache if for instance the dependencies change. But maybe I'm missing the main point why you wanted to have a look at the ghcr in the first place @apyrgio ?

[apyrgio]

Damn, super exciting work Alexis! I'll dig into it soon.

---

On the subject of caching, I'm wondering how is the invalidation story different for caches, instead of container images? I'm definitely missing context here since I have theorized about this working, but I didn't implement it as you did.

In any case, I suggested pushing to a container registry instead of creating a tarball for the following reasons:

1. We can re-use these container images in other CI actions (think apt-tools-prod / yum-tools-prod). We can even give them a check locally in case of a CI error, without waiting for image rebuilds.
2. Pushing the Dangerzone container image to GHCR may help with independent container updates.
3. It will speed up image uploads/downloads, in case some layers are already present (think the base Debian/Fedora layers, and maybe some extra ones if only a later portion of the Dockerfile changes)."
4. Artifacts like Tesseract data (soon to come) won't be evicted in case of lots of dev container images.

That's mostly it, but I'd like to know your experience so far.