Enforce zeroizing on generic secret keys

[AaronFeickert]

Earlier work in PR 137 improves zeroizing support in the RistrettoSecretKey and RistrettoPublicKey types. However, neither of the generic SecretKey and PublicKey traits require zeroizing or zeroizing-on-drop support.

It may be useful to add trait bounds for these, in order to enforce better key hygiene at the trait level. We can already trivially add a Zeroize bound to both. However, much more useful would be to add a ZeroizeOnDrop bound to SecretKey, which requires that any implementation zeroize secret keys on drop. This can be especially useful in conjunction with other constructions, like signatures, that are defined generically.

The problem is that the current zeroize version does not support the ZeroizeOnDrop marker trait, instead only offering a custom macro for this purpose. The options are to either add our own marker trait and manually implement it for the Ristretto key wrappers (and any future key types), or update zeroize across the board and then replace the zeroize-on-drop macro with the more current #[derive(ZeroizeOnDrop)] macro. Updating to a "proper" version would conflict with the curve library. However, manual testing shows that a zeroize update in the curve library introduces no test failures (nor any failures on bulletproofs or bulletproofs-plus, which are dependencies of this crate).

I think this is another point in favor of doing a custom curve library fork. It seems unlikely that upstream curve library PRs will be accepted. Maintaining a fork seems straightforward, as upstream is infrequently updated. Further, this would enable functionality like precomputation support in bulletproofs-plus. The changes introduced by both of these features are minimal, suggesting little to no effort for ongoing maintenance; and no changes are breaking in a meaningful way that would prevent later reverting back to upstream.