Should the `p64` functions be gated under `aes`?

Currently we gate a lot of p64 functions under aes, but I couldn't spot any pattern on when we add aes. We have aes in the following functions

• vld1{q}_p64{_x2,_x3,_x4}
• vld{1,2,3,4}{q}{,_dup, _lane}_p64
• vmull{_high}_p64
• vs{r,l}i{q}_n_p64
• vst1{q}_p64
• vst1{q}_p64_{x2,x3,x4}
• vst{2,3,4}{_lane, q_lane,}_p64
• vcreate_p64
• vreinterpret_*_p{64,128}
• vreinterpret_p{64,128}_*
• vset{q}_lane_p64

whereas, the following functions, even though they have a p64 argument, don't have aes

• vceq{z}{q}_p64
• vcopy{q}_lane{q}_p64
• vdup{q}_lane{q}_p64
• vextq_p64
• vldap1{q}_lane_p64
• vtrn{1,2}q_p64,
• vtst{q}_p64
• vuzp{1,2}q_p64
• vzip{1,2}q_p64
• vadd{q}_p64
• vget_{high,low}_p64
• vget{q}_lane_p64
• vreinterpret{q}_{f32,f64,s64,u64}_p64

The only reference of this in ACLE I could find was the fact that GCC gates all p64 functions and types under target ("fpu=crypto-neon-fp-armv8"), but afaik this does not translate to the Rust feature aes. I believe the closest would be the LLVM codegen feature crypto.

@rustbot ping arm

Start by comparing the listed p64 functions with the ACLE reference and GCC's target ("fpu=crypto-neon-fp-armv8"), then determine whether Rust's aes feature corresponds to LLVM's crypto feature. Done means there is a settled gating rule for each listed function group and the relevant implementation or tests reflect it.