RFE: Utilize hwcaps mechnism for sub-arch detection (+ more)

[pmatilai]

It's absurd that rpm has all manner of assembler magic to perform cpu detection. Rpm is not interested in the cpu bits and flags and their weird names at all, the only really relevant thing is somehow mapping toolchain optimizations to packages, and their compatibility with whatever is we're currently running on.

Toolchains + libc's have their own mechanism for this: hwcaps. We can outsource the cpu capability detection to libc by pushing the rpm uname -p counterpart to a dynamically loaded library and let the libc load the right one for us. At the minimum, it just needs a function to return the processor name, but there are almost certainly all manner of other opportunities in this direction.

Some potential uses could be

• eliminate/isolate cruft in rpmrc.c
• dynamic rpmlib() (or similar) provides
• support adding new/custom architectures without having to touch rpm code

Inspired by discussion in #2315

[Conan-Kudo]

To the best of my knowledge, hwcaps are not supported by musl-libc (@richfelker, can you confirm?) and other non-glibc platforms that RPM is commonly used on.

[Conan-Kudo]

I think it'd be worth looking at @dmach / @ffesti's libparch to get us a consistent way to handle all this. Then everything in the ecosystem can rely on a single mechanism (libsolv, librpm, libdnf, etc.).

[Vogtinator]

__builtin_cpu_supports might be complete enough meanwhie or in the future