Move secp256k1 support into ecdsa

[drHuangMHT]

Crate ecdsa supports keys generated with secp256k1, secp256r1 and secp384r1. I think the move is safe because the spec only says the key should be encoded in pkcs#8 format. Changing implementation does not change how the key is encoded, so there shouldn't be any compatibility issue. Plus, we use p256 for dealing with ECDSA keys, which only supports secp256r1 curve, and we use libsecp256k1 for secp256k1 keys. Both crates don't support encoding keys into pkcs#8 format, which is the problem we want to address in #3681.

[thomaseizinger]

As far as I know, https://docs.rs/libsecp256k1/0.7.1/libsecp256k1/ has received an audit where as ecdsa didn't. Given that we now have #2173, the feature is already optional unless you explicitly use secp256k1. I'd expect modern libp2p applications to only use ed25519 because the keys are much smaller and the operations faster.

Not sure if the risk of moving from an audited to a non-audited crate is worth the benefit of a reduced dependency tree for those (what I'd consider legacy) applications that rely on secp256k1.

[mxinden]

Agreed with the reasoning by Thomas.