For curve25519-dalek, overflow doesn't happen in field AddAssign for a collaborative prover

[weikengchen]

This PR propose a different way to add two numbers for ed25519's Fq elements.

We observe that ed25519's Fq is smaller than 2^{255}. If the prover is collaborative, all the "denormalized" numbers should be small than 2^{255}, overflow should never happen. So, it is safe to enforce that the carry7.0 is zero.

With the assumption that carry7.0 is zero, we can use the mul_mod syscall to reduce it to be smaller than the modulus. For a collaborative prover, it can make sure that the result is smaller than 2^{255}. If a prover is not collaborative, the number may be higher---this would not be disastrous because if it doesn't cause an overflow, it is okay, if it causes an overflow, the code would detect and refuse.

This change reduces the number of cycles caused by AddAssign.