Query SVE vector register length in host target computation for ARM cpus with SVE/SVE2.

[zvookin]

Attempts to fix automatic target resolution setting SVE/SVE2 flags without a vector length as reported in issue #8529 .

Someone will need to test this on hardware that supports (at least) SVE. E.g. an AWS Graviton 3 or 4 system. I will not be able to do that personally in less than two weeks or so.

[zvookin]

Note that the strangeness with only using __aarch64__ is trying to prevent compiling GCC/clang asm syntax on a random compiler that doesn't support it. I'm not real happy with the multiple preprocessor defines being used in the preexisting code, but also don't want to change existing behavior for this. The conditional compilation structure in Target.cpp is ripe for cleanup as well.

[zvookin]

So far as I can tell, none of the build failures have anything to do with this PR.

[alexreinking]

This seems fine, but I don't have a good way to test it. Also, it seems that it won't fix the issue in #8529 because that looks to be caused by a false-positive detection of SVE2 support... somewhere? Either in an old Linux kernel (Ubuntu 20.04 LTS is affected, but 24.04 LTS is not) or VMWare Fusion's CPU emulation.

[stevesuzuki-arm]

I've confirmed this change fixes the issue on Graviton 4. I'd like this to be merged sooner rather than later because it should happen other Neoverse based cloud CPUs such as Grace, Axion, Cobalt, etc.

[zvookin]

If Steve has verified this, it should get merged. I got as far as building on AWS and verifying it works on a couple setups but didn't get as far as spooling up a Graviton 4 instance. That said, it's a pretty trivial change, apparently it works, and it prevents the host CPU detection code from producing a target specification that is guaranteed to fail.

Per the rest of that issue, it's clearly a bug in other software, which appears to have since been fixed. That issue can be closed when this is merged.