Add support for xray in aarch64 unknown none target

[odlot]

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.

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[rustbot]

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[odlot]

@wesleywiser were you able to take a look yet? As far as I can tell CI failed because CI was in general broken at that point in time, I unfortunately can not rerun the pipeline.

[bors]

☔ The latest upstream changes (presumably #149581) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.