`cpu_arm_linux.c` and `cpu_aarch64_linux.c` unconditionally require `getauxval` / `<sys/auxv.h>`

### Problem:

`crypto/fipsmodule/cpucap/cpu_arm_linux.c` and `crypto/fipsmodule/cpucap/cpu_aarch64_linux.c` unconditionally `#include ` and call `getauxval`. These are glibc extensions also provided by musl and recent uclibc-ng, but not by older uclibc/uclibc-ng, which causes a hard build failure:

```text
.../cpu_arm_linux.c:10:10: fatal error: sys/auxv.h: No such file or directory
10 | #include
| ^~~~~~~~~~~~
```

Reported downstream for a uclibc-based `armv7-unknown-linux-uclibceabihf` target: https://github.com/aws/aws-lc-rs/issues/1108

Users can work around this by defining `OPENSSL_STATIC_ARMCAP`, but that isn't easily discoverable and users hit the build failure first.

There's already precedent for gating `getauxval` behind a feature macro in `crypto/rand_extra/urandom.c` (`OPENSSL_HAS_GETAUXVAL`), but it's keyed only off `__GLIBC_PREREQ` and so doesn't help non-glibc libcs that might lack `getauxval`. Generalizing that pattern (e.g. via a CMake build-time probe) and applying it to the ARM/AArch64 cpucap sources with a fallback to `/proc/self/auxv` or `/proc/cpuinfo` when `getauxval` is unavailable would let these targets build out of the box while preserving runtime detection where possible.

### Related Issues:

* https://github.com/aws/aws-lc-rs/issues/1108

Start with crypto/fipsmodule/cpucap/cpu_arm_linux.c and cpu_aarch64_linux.c, then read the OPENSSL_HAS_GETAUXVAL precedent in crypto/rand_extra/urandom.c. Inspect the CMake configuration for a capability probe. Done means affected uclibc ARM targets build without OPENSSL_STATIC_ARMCAP while retaining runtime detection when getauxval is available.

Written by the indexing model from the issue text.