Substantially reworked Dockerfile

[moritzheiber]

Note: this is a carbon copy of mastodon#20678, which I don't believe will see quick adoption, but I wanted for Glitch to have a better UX for working with containers as well

This PR splits the current monolithic Dockerfile into two parts, one of which is now executed in a separate pipeline (and repository).

Why

The current Dockerfile builds a new version of Ruby every time the image is built. That's wasteful and slow, especially since we're building against other targets than linux/amd64 (which is even slower; at least until GitHub Actions finally gets native linux/arm64 support).

Additionally, the Dockerfile now relies on the official NodeJS and Ruby images from the Docker Hub to build its assets, meaning there is no more overhead for the contributors in this repository to care for updating/maintaining Ruby and NodeJS installations and stacks (but rather source them from the Hub directly).

Consequences

• The image is now based on Debian, since the official "slim" images are based on Debian, specifically "Bullseye". I also could've gone for Alpine, but I faintly remember there being issues with Ruby on Alpine under certain conditions and especially when jemalloc is involved.
• The image relies on a new Ruby image, built in a separate repository, for its source of the Ruby interpreter. Aside from a few cosmetic changes, its instructions haven't changed much. The plan is to move this repository into the mastodon organization as soon as it's feasible. We can also add any number of Ruby versions or supported architectures to the image itself, should it become necessary.
• I've removed the platform instructions at beginning, as one shouldn't be cleverer than the actual operator. If you're building this image with an unsupported architecture you'll just receive an error from Docker/containerd.

Notes

Most of the stuff I either removed or left out was cosmetic or "solved" by using a different syntax (e.g. WORKDIR instead of cd, passing the --chown flag to ADD instead of using chown manually etc.).

The the already existing pipeline it should be split its runtime in half, maybe even reduce it be a larger amount.

[ineffyble]

The upstream PR was merged mastodon#20933 so this can probably be closed and have the change pulled as part of upstream sync.