aes: disable aarch64_aes backend on Miri

[newpavlov]

See this comment.

Closes#585

[newpavlov]

@RalfJung
I get a weird error while running RUSTFLAGS="-C target-feature=+aes" cargo miri test on this code:

running 2 tests
test aes/src/lib.rs - hardware_accelerated (line 197) ... ok
test aes/src/lib.rs - (line 58) ... FAILED
failures:
---- aes/src/lib.rs - (line 58) stdout ----
Test executable failed (exit status: 1).
stderr:
error: Undefined Behavior: calling a function that requires unavailable target features: aes
--> aes/src/lib.rs:236:47
|
= note: Undefined Behavior occurred here
::: aes/src/lib.rs:539:1
|
= note: in this macro invocation
|
= help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
= help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
= note: stack backtrace:
0: <aes::Aes128 as aes::cipher::KeyInit>::new
at aes/src/lib.rs:236:48: 236:82
1: main::_doctest_main_aes_src_lib_rs_58_0
at aes/src/lib.rs:12:14: 12:31
2: main
at aes/src/lib.rs:42:3: 42:38
= note: this error originates in the macro `impl_key_init` which comes from the expansion of the macro `define_aes_impl` (in Nightly builds, run with -Z macro-backtrace for more info)

Is it expected?

UPD: It gets "fixed" by passing RUSTDOCFLAGS="-C target-feature=+aes", but I think it's a weird interaction nevertheless.

[RalfJung]

UPD: It gets "fixed" by passing RUSTDOCFLAGS="-C target-feature=+aes", but I think it's a weird interaction nevertheless.

This is cargo behavior, Miri isn't involved here. I agree it is confusing, I don't know why they decided to split RUSTFLAGS and RUSTDOCFLAGS.