Add aarch64 builds

[surdy]

I recognize that this is a rather big set of changes from a fly-by contributor. Hence I would love to have a detailed conversation either on this PR or one of the maintainers preferred channels.

I started working on this when I realized I should try to give this a go. One thing led to another I found myself deep into annals of github actions and multi-arch containers.

I have purposely kept my (multiple) commits instead of squashing into one as it might be easier to review. I am open to squashing into one if that is preferred.

There are certainly decisions/assumptions I made while making these changes and I want to highlight them here:

1. Switched from quay.io/fedora-ostree-desktops/base to quay.io/fedora/fedora-silverblue to get kernel version
   I did this since I could not find a way to get aarch64 versions from quay.io/fedora-ostree-desktops/base. I hope it was a reasonable change

2. Skipped aarch64 for some flavors (e.g. bazzite, fsync, fync-ba, surface)
   I could not find aarch64 repos for them so I assumed they do not exist. I googled as well as dug through download pages for respective Copr repos.

3. Kept regular tags for flavors where there was no aarch64
   For single architecture images I used regular tags (like before) but switched to manifests for ones with multiple architectures. Alt approach could have been all platform independent tags (e.g. 40, 40-6.12.9) manifests instead of regular tags even for the ones with single entry. Honestly should not make a big difference usage wise

4. Clean up considerations
   I think there should not be a need to update the cleanup-old-images.yml. But I'm not 100% sure.

5. Additional tags??
   I was debating adding additional tags such as 40-x86_64, 40-6.12.9-x86_64, 40-6.12.9-aarch64, 40-aarch64 but ended up not adding them. Any new tags you want to introduce.

I did not do any testing on the built images . I just checked that they build and the tags / manifests looked correct (https://github.com/surdy?tab=packages&repo_name=kernel-cache)

[surdy]

Wow !! I just saw this https://universal-blue.discourse.group/t/bluefin-lts-alpha-for-arm/6545. I know LTS is a different upstream( Centos ) but a lot of work there might translate to Fedora based releases as well. I will keep this up in case one of the maintainers see value in this. If this is redundant as a result of LTS work , I can bow out.

[tulilirockz]

Nope! This is amazing and its completely necessary.

[bsherman]

I'm curious to see it run, so I pushed the button. :-)

Thank you for the submission @surdy ... However, I am in the middle of merging this repo's builds with those from our akmods repo... so I'd prefer to wait on the addition of new complexity until that PR has merged.

If the change was simpler, didn't double our artifacts, etc, I would be more open to merging this first.

@m2Giles any thoughts?

[surdy]

Makes sense. Found ublue-os/akmods#266 just today. I will close out this for now. Watch the work on ublue-os/akmods#266 and rework this.
Until then I will also figure out why the pr-<num>-<kernel-version> thing failed and fix that.

Then perhaps I can rebase on the merged repo.

Also I would love to collaborate. Let me know how.

[m2Giles]

This is very impressive, but our more pressing issues is the merged repo. We need to shore up some of the issues first before expanding the infrastructure.

Once that has happened, I very much want to see us continue with this path.