Add validations for zero values

[mj850]

This PR:

• Adds validations for each VerifyXProof method to ensure that the components of the proof are not nil and also not zero or the identity point (The zero point of the curve)
• Adds a method to ensure that we do not generate 0 when generating scalars

Explaination:
As part of the audit, a bug was caught where by generating the CiphertextCommitment proof in a certain way

1. Setting the yx, yr to kx and kr instead of random values (Where k is an arbitrary scalar value)
2. Setting Y2 to 0
   the attacker can get the ValidateCiphertextCommitment to return true even though the Ciphertext and Commitment encrypt different values.
   Specifically, the commitment must encrypt x * (c + k) * c_inv, where
   k is any random scalar
   x is the original value encrypted by the ciphertext
   c is the challenge scalar of the proof, which can be independently generated using the params in the proof
   The implication is that the attacker would be able to create a transfer/withdrawal for more than they have.
   Eg:
   Account state: AvailableBalance: 100
   Withdraw {
   WithdrawAmount: 150 (Exceeds AvailableBalance)
   NewAvailableBalanceCommitment: (-50 * (c + k) * c_inv) - This is a specific value calculated by the attacker.
   RangeProof that NewAvailableBalanceCommitment is > 0 - This will pass assuming the fake NewAvailableBalanceCommitment above is +ve
   EqualityProof that NewAvailableBalance == Account.AvailableBalance - WithdrawAmount - This is the fake equality proof
   }
   This withdraw instruction will pass, since the range proof is valid and the equality proof is valid.

This can be mitigated by adding zero checks to the proof.
While this was only flagged for the proof above, this PR adds zero checks to all the parameters in the proof.

Zero values in the proof could suggest a lack of randomness when generating scalars and lead to degraded proofs, since the values may no longer be blinded, or the proof could be exploited in some edge case.

In all of the cases for our proofs, zero values arise when a random scalar we generate is 0 or specifically cancels out another value. Since we generate random scalars on a field of 2^255 points, the probability of generating such a scalar is 1/(2^255) and effectively negligible

Since we still want to eliminate random chance failures due to generating 0, also adds a method to make it impossible to generate the 0 value randomly when we generate random scalars, failing on the proof generation side if it happens instead of at validation time.

[dssei]

Can we add a test that proves the change works?
E.g. the test without change fails, passes with this change

[dssei]

Also would be nice to have a test for this method. To be fully testable we have to have a good handle of the main collaborator which is curve.Scalar.Random in this case. I think for that we could have our own interface that returns a random scalar. We pass interface instead into the method. Real implementation still uses curve.Scalar.Random to generate scalars. At least one test implementation returns always zero to test for error case.

[mj850]

Won't fix for now since this method is quite simple and the change required to make this testible is a bit weird. But agree that it would be good to have test coverage here eventually in case things change.

[mj850]

Added a basic test for this method though