There's some hopefully good code comments describing this better, but essentially this changes the algorithm to have the "first" tag/entry in the SharedTag group be the "owner" of all the shared tags (instead of the following tags clobbering that and them thus being "owned" by the final Windows entry).
Before (finding tags which have both Debian *and* Ubuntu in their parentage):
```console
$ comm -12 <(bashbrew children debian | sort) <(bashbrew children ubuntu | sort) | cut -d: -f1 | sort -u
$ # (empty list, but adding "--arch-filter" makes it work:)
$ comm -12 <(bashbrew children --arch-filter debian | sort) <(bashbrew children --arch-filter ubuntu | sort) | cut -d: -f1 | sort -u
clojure
maven
neo4j
```
After:
```console
$ comm -12 <(bashbrew children debian | sort) <(bashbrew children ubuntu | sort) | cut -d: -f1 | sort -u
clojure
maven
neo4j
```
- "workflow_dispatch" so we can trigger manually
- "concurrency" so we avoid over-triggering when updating PRs/branches
- multi-line string in GITHUB_OUTPUT for better output and less flakiness
This is pulled in automatically via `gnupg`, and moved from `Recommends` to `Depends` in 99474ad900, which has been part of `src:gnupg2` since 2.1.21-4 (and every supported version of both Debian _and_ Ubuntu have 2.2.x 😇).
Since Docker's image store can't represent these, we round trip them through our self-managed (or external) containerd image store, which also makes pushing more efficient.
In other words, instead of `ubuntu:22.04`, we should store it as `docker.io/library/ubuntu:22.04` (which Docker then converts appropriately on `docker load`).
This makes it a lot easier to see/debug what's going wrong:
```console
$ BASHBREW_CACHE=/tmp/foo bashbrew fetch --arch-filter ubuntu:bionic
failed fetching git repo for "ubuntu" (tags "18.04, bionic-20230126, bionic" on arch "amd64")
failed fetching "f127810992c0981574cc137b9c83937ca1a304dc:refs/remotes/temp3848952252/temp": server does not support exact SHA1 refspec
failed finding Git commit "f127810992c0981574cc137b9c83937ca1a304dc" after fetching "refs/tags/dist-bionic-amd64-20230126:refs/remotes/temp3848952252/temp": object not found
```
This *should* be generally safe since we got most/all downstream consumers to pin to a release (or they're building bashbrew from the same commit they're getting the script from).
Docker media types inside OCI media types is semantically fine (and Docker sure doesn't care), but technically invalid, so this increases our validation from just the manifest media type all the way down to the config and layer media types also.
In many, many, many scripts I have encoded the horrible assumption that `ArchDockerFroms` will ensure our Git repository is fetched (which is a side-effect of that function). With the implementation of `Builder: oci-import`, that side effect is not necessary for returning an accurate result in these new images. Instead of working around this in bad ways, I've decided to finally bite the bullet and add an explicit `bashbrew fetch` command that can make sure all the underlying Git commits are fully fetched into the local cache.
yosifkit