Make `HpkeError::Secp256k1` variant an opaque `HpkeError::InvalidPublicKey` error

[DanGould]

arguably the HpkeError::Secp256k1 variant also leaks implementation details

— @nothingmuch

I have no problem exposing this as an opaque error variant without an encapsulated secp256k1::Error if you also find that more appropriate. From what I can tell these are always thrown from secp256k1::PublicKey::from_slice as Err(InvalidPublicKey), and our own HpkeError::InvalidPublicKey variant would handle much the same way as encapsulating secp256k1::Error currently does

Originally posted by @DanGould in #496 (comment)

[nothingmuch]

Hmm, I'm pretty agnostic to this, if anything I'm leaning on the side of this is an OK detail to leak (so #wontfix on this issue i guess) because realistically there isn't going to be another production quality implementation of this curve, if one materializes we can just bump the right semver digit as we agonize of that ;-)

I really only pointed it out for consistency

[DanGould]

I also think unless you really need the internal error, you should not accumulate the complexity of encapsulating it. So this is a problem to fix in #403