[Enhancement]: AARCH64 / ARM64 / ARMv8 / ARMv9 support

### Problem / Motivation

Didn't find any mentions for some reason, but it will be really good to see Arch-based distro for ARM64, aside from the not-so-stable ArchLinuxARM. I can't say precisely which targets should be supported, but there are several interesting machines, such as TBD Steam Frame (Qualcomm Snapdragon 8 Gen 3) and my own Radxa Orion O6 (Cix P1 / Sky1). The latter supports ACPI and may be used almost fully without external patches if dGPU is installed, but also there are several solutions to provide full support, like [these patches](https://github.com/cixtech/cix-linux-main) for Linux 6.18, 7.0 and 7.1. You probably don't need it, but the upstream status of DT (Device Tree) drivers can be found [here](https://github.com/cixtech/linux-mainline/wiki).

Some other interesting targets may also exist, but I can't provide more information which exactly. Maybe some generic devices with ACPI support, listed as supported in [PostmarketOS Trailblazer](https://wiki.postmarketos.org/wiki/PostmarketOS_Trailblazer_(postmarketos-trailblazer)) or which may be supported but not listed, also there some AYANEO devices or similar with ARM64 CPU. To be more precise, AYANEO doesn't provide any Linux support for ARM64 devices, but in some cases this isn't an issue due to community work, like stated [here](https://wiki.postmarketos.org/wiki/Ayaneo_Pocket_S2_(ayaneo-pocket-s2)). And no, I was never talking about generic Raspberry Pi's and other SBC's with very low performance, but about high-performance SoCs, like Qualcomm Snapdragon Elite and others.

### Proposed Solution

I want to propose several changes for the nearby future:

- Provide generic ARMv8.2-A and ARMv9-A repositories without a kernel
- This architecture split is to support as many devices as possible in addition to more new and capable SoCs. Think of it as `x86_64-v2` and `x86_64-v4` targets in the ARM64 world. For example, Cix P1 processor has ARMv9.2 cores and generic ARMv8.2 will leave them without _pointer authentication_, SVE and other available features.
- Port patches for ARM64 flavor as a part of generic Linux kernel, e.g. without device-specific patches
- Define and provide support for hypothetical tier-1 and tier-2 targets
- I can't say definitely what actually means these tiers for you, but in my opinion tier-1 should include upstream-first devices without (almost) any additional patches to run them with a full hardware support, such as Valve Steam Frame or generic ACPI, and tier-2 may include specific devices with good support, but with additional (vendor-specific) patches, often with their own kernel image

### Alternatives Considered

If it's impossible to provide ARM64 support at all, because of strict requirements for the infrastructure, maintainers' decision to support only `amd64` architecture, high resource cost for CI or any other kind of disagreement, I thought about these alternatives:

1. Provide ARM64 bootstrap image to build your own ISO and/or repository
2. Write and maintain some instructions on compiling latest available CachyOS sources for ARM64 architecture from ground-zero (e.g. without even a bootstrap image)
3. Invest some time and efforts into the future ARM64 support with an ability for users to build it (like first option, but also includes development towards this architecture support)

### Additional Context

To be honest why am I asking for this, there's some context I should share with you. Since my current, and in fact main, desktop machine is Radxa Orion O6 with ARM64 CPU, there aren't that many Linux distributions I can choose between. After several NixOS deployments, Debian and Ubuntu installations, painful Fedora support and a few other frustrations inside my room, I've settled on Gentoo as a perfect distro to build my dream PC, which had no stability issues itself or overcomplicated maintenance process, in my opinion. It still fits my needs in general, but it's getting too heavy to maintain for a single, local user. For now, I'm searching for an alternative, which will work and will not require so much effort to maintain it. That's a reason I created this issue here and this should also explain the reasoning behind my earlier proposals, such as architecture split. I hope you'll read the issue carefully and we can discuss in detail with other engaged people.

No files, tests, or entry points are named. First inspect the repository's current architecture, kernel, repository, ISO, and CI requirements, then determine whether generic ARMv8.2-A and ARMv9-A targets are feasible. Done would require an agreed support scope, target tiers, and an implementation plan covering the proposed ARM64 distribution support.

Written by the indexing model from the issue text.