Add arm64ec support

[dpaoliello]

The Rust Compiler has recently added support for ARM64EC (rust-lang/rust#119199), so this change adds support for ARM64EC to portable-simd by enabling the same code as AArch64.

[calebzulawski]

Since I don't really have any way of testing this--is this truly a different target_arch, rather than a different ABI that modifies target_feature? I ask because it appears to be a variation of aarch64, and there are already lots of checks in both std and community crates that use target_arch = "aarch64" that I would think should automatically support ARM64EC.

[dpaoliello]

Since I don't really have any way of testing this--is this truly a different target_arch, rather than a different ABI that modifies target_feature? I ask because it appears to be a variation of aarch64, and there are already lots of checks in both std and community crates that use target_arch = "aarch64" that I would think should automatically support ARM64EC.

Arm64EC isn't just a target feature or ABI of AArch64 - it ends up being a hybrid of AArch64 and x64 where developers need to choose the correct arch to follow at each point.

For intrinsics and assembly, it should reuse the AArch64 code (mostly: the assembly can end up being wildly different depending on what limitations you run into and OS interactions).

However, for interacting with the OS and other applications, then Arm64EC should act like x64. For example, in the backtrace library we use the x64 structs and functions: rust-lang/backtrace-rs#587.

If we were going to make Arm64EC pretend to be another arch, it would be better to treat Arm64EC as a target feature of x64 since using the wrong shape for external APIs is a correctness issue, whereas using the wrong intrinsics can be worked around by reimplementing the x64 intrinsics in AArch64. This is the approach that MSVC has taken, as it sets the predefined macros for x64 not AArch64 and then reimplements the intrinsics in softintrin.lib: https://techcommunity.microsoft.com/t5/windows-os-platform-blog/getting-to-know-arm64ec-defines-and-intrinsic-functions/ba-p/2957235. You can also see from the examples at the end of that article how much of a mess Arm64EC pretending to be x64 turns into. This also doesn't help with assembly: if we ban assembly then that is likely worse than Arm64EC having its own arch (since it guarantees an error, rather than the crate possibly falling back to some default "unknown arch" implementation) but to support it would require outlining the x64 assembly so that LLVM can generate the correct thunks (which feel like a lot of effort to generate suboptimal code).

Instead, for Rust, we decided to make Arm64EC its own arch so that these decisions are explicit, although I do acknowledge that this does create a bunch of work for library maintainers to support yet another arch despite it reusing code from one of the existing archs.

[dpaoliello]

For anyone who is interested, there is a good thread over in the stdarch repo on why Arm64EC is its own target_arch: rust-lang/stdarch#1550 (comment)