This is the the first PR to introduce a Crypto API for our library.
Summary and thoughts:

• The API tries to follow Rust Crypto. Names are similar where reasonable. To proof its compatiblity, you can switch the test env to the p256 crate (run
  cargo +nightly test --release --features std,ed25519,with_ctap1,vendor_hid,rust_crypto in libraries/opensk/
  ). I couldn't test it on hardware yet, I didn't find a Rust compiler version that works for both Tock v1 and p256 with its dependencies. Numbers on binary size will be meaningful only after a full port, since p256 uses sha2 for signing, so we currently have overlap.
• The CoseKey type doesn't easily translate. I intend to keep all types that are used in parsing commands (rule of thumb: converts to CBOR) free of Env. CoseKey is one of them. The From and TryFrom replacements in this PR could be improved in a follow-up PR. Best case the compiler could again ensure that we don't create an ECDH CoseKey from a ECDSA public key and vice versa.
• The crypto implementations in TestEnv and TockEnv are currently identical. I was wondering if they TockEnv should just import TestEnv, but kept them fully independent for now. This way I don't have to mess with the conditional compilation and it's easier to change only one of them later (e.g. hardware crypto).
• I introduced shorthands like
  pub type EcdhSk<E> = <<<E as Env>::Crypto as Crypto>::Ecdh as Ecdh>::SecretKey;
  Seems to me to be the best way to have less noise. The trait imports still look a bit clunky, as SecretKey has the same name for ECDH and ECDSA. Which makes sense inside its namespace, but needs extra work when useing them. One option is to split the traits into multiple, like replacing the ECDSA SecretKey with a general SecretKey that has a random and a public_key function, together with a Signer trait. But I feels like unncecessary complexity to me.

Curious about your thoughts!