[refactor] #3240: Guard against secrets leakage

[dima74]

Description

• Added Secret to PrivateKey. Access to inner PrivateKeyInner now requires import of ExposeSecret trait via expose_secret method
• Display, Debug and Serialize implementations for PrivateKey now returns "[REDACTED]"
• Added ExposedPrivateKey wrapper which can be formatted and serialized as usual
• Note that I don't used secrecy crate because it requires to implement Zeroize trait, but inner key struct (ed25519_dalek::SigningKey) implement only ZeroizeOnDrop, and not Zeroize. So I used modified version of Secret which requires ZeroizeOnDrop instead of Zeroize. This potentially could be controversal, so any suggestions are welcome

Linked issue

Closes #3240

Checklist

• I've read CONTRIBUTING.md
• I've used the standard signed-off commit format (or will squash just before merging)
• All applicable CI checks pass (or I promised to make them pass later)
• (optional) I've written unit tests for the code changes
• I replied to all comments after code review, marking all implemented changes with thumbs up

[mversic]

I was thinking that this change won't affect iroha_crypto crate. IMO This should be an external functionality and not integrated into iroha_crypto, the change should be in iroha_config mostly

[dima74]

To summarize today discussion:

• Current implementation:
  • Add Secret inside PrivateKey
  • Disadvantages: new public struct ExposedPrivateKey in iroha_crypto crate
• Alternative implementation:
  • Add secret to usages of PrivateKey in other crates, such as iroha_config
  • Disadvantages: easy to forget to add Secret in case new PrivateKey field added to some struct in future

The plan is to merge current implementation as-is if no new concerns arise