Rollup merge of #148666 - odlot:master, r=wesleywiser

Add support for xray in aarch64 unknown none targets

I am currently working on an embedded project and use the target `aarch64-unknown-none`, which I want to profile.
I found the following compiler flag `-Z instrument-xray` (https://doc.rust-lang.org/unstable-book/compiler-flags/instrument-xray.html) available and I locally built a toolchain that sets the `supports_xray: true` option in `TargetOptions` for `compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs`.
Using this toolchain in `rustup` I am able to use the instrumentation pass and I verified that the disassembly looks as what I want.
I understand that it isn't available upstream while being supported due to the separate runtime library which has to be linked (e.g., https://www.llvm.org/docs/XRay.html#xray-runtime-library), which is not available for `aarch64-unknown-none`.
I argue that someone who cross-compiles for `aarch64-unknown-none` would be okay with writing a separate runtime library themselves, which I intend to do.
As far as I understood it is not necessarily required to have a runtime library at this point, i.e., the user of this API should link it, e.g., from their `build.rs` file using `cargo::rustc-link-lib=LIB` if there is an XRay LIB available for the respective target, e.g., `clang+llvm-19.1.1-aarch64-linux-gnu/lib/clang/19/lib/aarch64-unknown-linux-gnu/libclang_rt.xray-fdr.a` (which afaik there isn't for `aarch64-unknown-none`) and do "configuration as code" of XRay's options.
It should not be part of the compiler, because the instrumentation and the runtime library are completely decoupled. One can modify the instrumented code by the compiler pass however one wants to, this again pushes me into the direction of telling the developer to bring his own runtime library.

I would like to bring my change that enables this instrumentation back into upstream to facilitate my developer experience.