feat: Guarded trait for secrets protection guarantee

[therustmonk]

An attempt to find a good solution for #112 (comment) they led me to this implementation (an alternative to #112) and curious conclusions.

Description:
This PR introduces a special Guarded trait that forces an implementation to:

• always wrap a (secret) value to the GuardedWrapper (that implements Debug, but never prints the secret value)
• implement Zeroize for the secret (and it always be called by the GuardedWrapper)

The GuardedWrapper has a special method .reveal() that returns a reference to a secret.
The beniefit of that approach: we have .reveal() calls everywhere we get access to a secret value and we could grep sources to see all the places the secret is revealed. Like .unwrap() approach, but for secrets. It's always clear now in reviewing PRs where we get the secret value

Another change is removing From<RistrettoSecretKey> for Scalar implementation, because Scalar implements Copy and easily copied in that method, but the copied value will never be zeroized. The original secret key is zeroized, becuase Drop will be called after the From implementation:

impl From<RistrettoSecretKey> for Scalar {
    fn from(k: RistrettoSecretKey) -> Self {
        k.0 // copied scalar `leaked` here and will never be cleared (zeroized)
        // `drop(k)` is happened here that will call `k.zeroize()` 
   }
}

The drawback of that approach: we have to Clone values instead of Copy, because we couldn't have both Copy and Drop at the same time.
The extra costs for cloning could be eliminated by some refactoring to using references to secrets instead of owning them.

[CjS77]

I prefer the outcomes of #112 - even though it's a specific impl and not generally applicable to SecretKey.
This approach would require modifying every use of secret keys in the tari codebase to use GuardedSecret, right?

[therustmonk]

@CjS77 yes, it requires a lot of changes in the main repository. #112 is not so strict, but is a much faster way to solve the problem.

[CjS77]

Cool. Let's abandon this approach, and go with #112

[therustmonk]

Ok 👍