ci: build the compiler image on a prebuilt LLVM image (#5671)

* ci: build the compiler image on a prebuilt LLVM image

The Docker workflow built LLVM as the first stages of the compiler image. The
only thing that prevented a rebuild was the BuildKit registry layer cache. A
layer cache is a best-effort optimisation, so CI sometimes built LLVM again
although llvm-version.txt did not change.

Move the LLVM stages to Dockerfile.llvm and make the compiler image start from
that image through an LLVM_IMAGE build argument. The compiler build now holds
no LLVM build step, so it cannot build LLVM again.

Tag the LLVM image with the LLVM revision and a hash of the files that set the
content of the image: llvm-version.txt, Dockerfile.llvm, GNUmakefile, and the
files in make/. tools/llvm-image-tag.sh prints the tag, and CI and developers
use the same script. The workflow builds and pushes the LLVM image only when
the registry does not hold that tag.

Remove the object files and the git history from the LLVM image in the same
layer as the build. The CI caches already link against that subset, see
.github/actions/setup-llvm/action.yml.

Delete llvm.yml. It made an image that nothing used, and it needed a push to a
special branch. The Docker workflow now does the same work when it is
necessary, and the force-llvm input of the manual trigger makes the image
again.

The LLVM image goes to GHCR only, because only CI uses it. The compiler image
continues to go to Docker Hub and GHCR.

* ci: remove the LLVM git history in the layer that makes it

The removal was in the tinygo-llvm-build stage. This stage is below the
layer that makes the shallow clone. A later layer only hides files from a
parent layer. Thus the pack files stayed in the published image.

* ci: link the LLVM image to the repository

The label puts the package in the repository package list, so the package
settings are easy to find. BUILDING.md now tells you to build LLVM locally
if you are not able to pull the image.

BUILDING.md

@@ -45,6 +45,9 @@ It provides a help target for quick reference:
     tinygo                          Build the TinyGo compiler
     lint                            Lint source tree
     spell                           Spellcheck source tree
+    llvm-image-tag                  Print the tag of the prebuilt LLVM Docker image
+    docker-llvm                     Build the LLVM base image (slow)
+    docker-tinygo                   Build the TinyGo compiler image
 
 ## Download the source
 
@@ -54,8 +57,8 @@ the git repository). Then, inside the directory, download the LLVM source:
     make llvm-source
 
 The LLVM commit to use is pinned in `llvm-version.txt`. A change to that file
-makes CI build LLVM again, because the file is part of the LLVM cache key. All
-other changes reuse the cached LLVM build.
+makes CI build LLVM again. The file is part of the LLVM cache key and of the
+Docker image tag. All other changes reuse the cached LLVM build.
 
 You can also store LLVM outside of the TinyGo root directory by setting the
 `LLVM_BUILDDIR`, `CLANG_SRC` and `LLD_SRC` make variables, but that is not
@@ -105,6 +108,29 @@ On macOS, use otool -L:
 
 The result should not contain libclang or libLLVM.
 
+## Build with Docker
+
+The Docker build uses two images. The LLVM image holds the LLVM build, and the
+compiler image holds TinyGo. The LLVM image changes only when
+`llvm-version.txt`, `Dockerfile.llvm`, or the make files change, so the slow
+LLVM build does not run again for each change to TinyGo.
+
+To build both images:
+
+    make docker-llvm
+    make docker-tinygo
+
+The first command takes 1-2 hours. To use the LLVM image that CI published
+instead of a local build:
+
+    docker build -t tinygo-dev \
+        --build-arg LLVM_IMAGE=ghcr.io/tinygo-org/llvm-22:$(sh tools/llvm-image-tag.sh) .
+
+`tools/llvm-image-tag.sh` prints the tag of the LLVM image for the current
+source tree, and `make llvm-image-tag` does the same. CI uses that script, so
+the tag agrees. If the registry does not hold that tag, or you are not able to
+pull it, build the LLVM image with `make docker-llvm`.
+
 ## Make a release tarball
 
 Now that we have a working static build, it's time to make a release tarball: