Remove the aes feature from many arm intrinsics

[adamgemmell]

Fixes #2109

The aes rust feature represents FEAT_AES and FEAT_PMULL - from the architecture reference manual, these just add 4 new aes* instructions, and the p64 variants of PMULL/PMULL2.

Clang's header doesn't seem to gate any poly types on the aes feature, and many of the intrinsics with the aes feature are nops or just load/stores, for which the aes feature shouldn't matter. Accordingly, I've removed the aes feature from all intrinsics except the vaes* intrinsics, and ones using the p64 variants of PMULL[2] instructions

[rustbot]

r? @folkertdev

rustbot has assigned @folkertdev.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Amanieu, @folkertdev, @sayantn
• @Amanieu, @folkertdev, @sayantn expanded to Amanieu, folkertdev, sayantn
• Random selection from Amanieu, folkertdev, sayantn

[folkertdev]

This changes public, stable signatures. I don't think it can be observed (it's just removing a constraint), but we should be careful.

Is there any way to validate that the new versions in fact work? I suspect that our CI just has the aes feature available anyway, so if any of these functions did still generate an aes instruction we'd not notice. Maybe qemu can be configured to just have neon, and not aes locally?

[rustbot]

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