AArch64: Mismatch between compiler features and runtime detection

[Amanieu]

While reviewing the list of target features, I noticed 2 inconsistencies between the list used by the compiler and the one used by stdarch for runtime feature detection.

Specifically these features are present as a separate feature in the runtime detection list but are folded into another feature in the compiler:

• fp can be detected at runtime but can't be enabled. It is instead implied by the neon feature.
• pmull can be detected at runtime but can't be enabled. It is instead implied by the aes feature, and all the related intrinsics use the aes target feature.

cc @JamieCunliffe @adamgemmell @workingjubilee

[adamgemmell]

On fp, I believe this was intentional, though it wasn't discussed deeply. This is because we judged that an OS could expose what it likes between the two (linux exposes separate bits for the two). This went a bit deeper in #1311 where I note that the two lists are now logically separate and allow for a mapping from runtime to compiler features. Maybe the question should be "is there a use for detecting fp at runtime without checking for neon?" We also can't remove the fp runtime feature at this point since it's stable. About the only thing I can think of that we can do is to make both runtime features query fp && neon, but I'm not sure what exactly that solves.

I think that question also applies regarding detecting pmull without checking for aes. If nothing else, I thing we should add FEAT_PMULL to the aes target_feature here and link the runtime feature to the aes target_feature.

I should probably also say that there's been no further sign that we can simplify target_features beyond merging fp into neon. This makes that situation more of an outlier than a simplification.

[sayantn]

This was resolved in #1527