Consistent composure of backend overrides

Several crates now support "override" for backend/s - people have different needs from top level binary

• curve25519_dalek_ [ backend | bits ] - Overrides
• https://github.com/dalek-cryptography/curve25519-dalek/issues/414

Ideally the selection is automatic but the overrides are provided e.g. wasm (both web and non-web) no_std runtimes etc.

I've also asked in several places to further the support:

• https://github.com/jedisct1/rust-aegis/issues/5
• https://github.com/crate-crypto/Ed448-Goldilocks/issues/36

This would be good given the compiler / cargo now has added features to validate the cfg use.

Typically people used features but as repeated in other issues - copied here;

• Allows top-level binary composing the primitive as the overarching choice and transients not having any say
• Transient dependencies don't need to "relay" it down - dalek long time didn't delay the choices down resulting only serial use
• The compiler has now taken official stance on it to support the pattern
• Composes as mutually exclusive feature vs features are not mutually exclusive
• Other issues discussed in the long winded ref'd issue

Especially with rustls ideally it would be target arch but we can't assume crypto primitives take the environemnt into account.

Especially in non-monolithic primitives that do only one thing - it's primitive scope - it's essential to not duplicate the environment handling to every single primitive composed into one package under it.

No files, tests, or entry points are named. Start by reviewing the existing backend override mechanisms referenced in this issue and the linked curve25519-dalek, rust-aegis, and Ed448-Goldilocks discussions; done would require a decided, consistent composition approach across the relevant crates.