feat: implement display/debug traits for private keys

[erwanor]

Fixes #14, at least partially! For the public keys, base64 will have to do until #1 is resolved.

For consideration: do you think a Secret derive macro that:

1. derives Zeroize
2. implements safe Display and Debug
3. implements unsafe_write_secret: &self -> String (for debugging)

makes sense? I could slot it into this PR. This would make the code nicer:

#[derive(SecretMaterial)]
 pub struct BLS12381PrivateKey {
     pub privkey: blst::SecretKey,
     pub bytes: OnceCell<[u8; BLS_PRIVATE_KEY_LENGTH]>,
     ...
}

[erwanor]

Reviewers: the first commit fixes cargo test

[punwai]

This is perfect @erwanor. It would be super nice to have a test or two. Otherwise, the PR looks good to me!

[erwanor]

Ah yeah good point, added a test for each.

[huitseeker]

Thanks @erwanor ! This is good, but a tad tedious to implement for each scheme, would it be worth implementing those as a proc-macro à la Diem?

[erwanor]

Neat thanks, I'll refactor with those macros

[kchalkias]

I'd personally avoid a diem dependency, especially because this code part is not complex to be ported (copy pasted with a comment reference) without maintainability issues. However, we can do in an upcoming PR. If we do in upcoming PR, please merge and add a github issue.

[erwanor]

I can do it now, but macros need their own special crate type, so we will have a nested crate fastcrypto::crypto_derive.

I'll push the changes shortly.

[huitseeker]

😍

[kchalkias]

Awesome! thanks