Add back (off-by-default) "soft-aes" feature

[tarcieri]

The aes crate v0.3 eliminated feature-gated fallback to soft AES.

This adds back a soft-aes feature to opt-in to a software implementation of AES on platforms where a hardware implementation is not available.

Right now the only supported hardware implementation is AES-NI. This approach mirrors the target gating used by the aes crate, and therefore unless the soft-aes feature is enabled this crate
will not compile on any other architecture besides x86(-64) with AES-NI target features enabled.

[tarcieri]

@newpavlov I think the aes crate would still benefit from a feature like this, even if it were enabled-by-default.

My personal inclination is to leave it off-by-default so users need to opt-in, but I'd be fine with the aes crate doing the opposite.

[newpavlov]

I am still not sure about use-cases for this feature flag. Can you elaborate why you may need it?

[tarcieri]

(See also discussion on #12)

@newpavlov right now it's difficult to tell if you are configuring target-feature correctly in order to receive the AES-NI implementation (which I needed for testing if that was the culprit for a performance regression I'm investigating and will open an issue about separately)

Per #12, it seems like without a more draconian mechanism, most people will not configure target-feature whatsoever, receive the software implementation instead, and go about their day.

I think in an ideal case, at least for me:

• On x86/x86_64, target-feature=+aes,+ssse3 would be required for the crate to compile. This may be easier to do with a per-target architecture workspace for these features.
• To support older x86/x86_64 CPUs without AES-NI, runtime CPU feature detection could be used, however this does not work inside Intel SGX, so really some way to allow the crate user to control this would also be ideal.
• Other CPUs would always get the software implementation, at least until additional hardware implementations become available.

I can open an issue about this on on https://github.com/RustCrypto/block-ciphers if you'd like.

[newpavlov]

I think if you want to ensure that miscreant is built with the required target-features, you can add cfg'd compile_error! with a warning and use aes crate as usual.

[tarcieri]

@newpavlov aah, indeed! I'll go ahead and make that change.