Restructure Docker build process

[straight-shoota]

While looking into adding support for aarch64 docker images, I noticed a couple of issues with the current docker build process.

• dist_docker builds the images, then stores them in a gzipped tarball in order to persist them in the workspace.
• The entire build step currently takes about 4 minutes. 90 seconds of that are spent for exporting the images to disk. It might be more efficient to just push the images to the registry and pull them again when necessary.
• The images are used by follow-up steps:
  • dist_docs: Loads the ubuntu-build image and uses it to build the API docs (the regular image should actually suffice)
  • test_dist_linux_on_docker: Loads the ubuntu-build image and uses it to run the entire test suite.
  • publish_docker: Loads all images and publishes them to docker hub
• test_dist_linux_on_docker itself seems very heavy (30 minutes) for little gain. A simple smoke test to make sure Crystal works should be good enough. Running the entire test suite is unlikely to fail. It could be considered an integration test for the compiler build itself (just packaged in docker). But even then it's quite a lot. Also, we're only doing this on a single platform.
• publish_docker depends on test_dist_linux_on_docker in releases, but not nightly releases. This inconsistency seems odd.

With support for aarch64 docker images, we'll be doubling the current number of docker images and their sizes.

Here's what I'd like to do in order to simplify the entire process:

1. Remove test_dist_linux_on_docker. We can replace it with a simple smoke test (build hello world: Add smoke tests to dockerfiles #391) directly in the dockerfile.
2. Publish docker images directly to the registry instead of persisting them to the workflow. dist_docs can pull the single image it needs.
3. Simplify the Makefile. It seems too be way more complex than it needs to be. With 2. we should end up running only single docker build command with a couple of parameters.

[straight-shoota]

And another note: While building the docker images, the most expensive operation is installing the dependencies. Extracting the Crystal tarball is super quick. But the dependencies usually don't change, and we wouldn't need to rebuild them every time. Caching would be great for this! It should bring down dist_docker build times from currently 5 minutes to a couple of seconds for repeated builds.

CircleCI offers a native Docker Layer Caching feature. It costs credits though. And it's a vendor lock-in.
So it's probably better to use docker buildx cache feature directly. It can cache to a registry, file system, or cloud storage (S3, azblob). GitHub Actions cache is also supported, but that doesn't help us on circleci.

Not sure what's the best solution here.
Registry seems pretty decent. Although, we probably shouldn't publish the cache to docker.io/crystallang/crystal. We could consider an alternative registry. Or just a different name (crystallang/crystal-cache for example).

There might be issues with cache-invalidation. For example, we might not get the latest greatest patch releases at the time of building the docker image.
But we don't update the images after the original release, so it's kind of expected that they may not have the latest package updates.