Add support for Ristretto255

[joernheissler]

This adds support for https://doc.libsodium.org/advanced/point-arithmetic/ristretto / https://ristretto.group/ I'll finish the docstrings and add documentation once the public interface is stable.

[reaperhulk]

We need some docs for the ristretto class, but this approach generally looks correct.

[reaperhulk]

Just a ping to see if there's a desire to finish the docs here so we can merge.

[joernheissler]

There is and it's on my ToDo short list :-) Hopefully some time next Week!

[reaperhulk]

I'd like to have this feature land in PyNaCl 1.5.0 so I'm holding that release a bit hoping we can get this in there first 😄

[reaperhulk]

(Ping)

[joernheissler]

Pong! (Really sorry for yet another huge delay)

[joernheissler]

Readthedocs needs a version update. Then docs build too:

• https://joernheissler-pynacl.readthedocs.io/en/latest/ristretto.html
• https://joernheissler-pynacl.readthedocs.io/en/latest/api/ristretto.html

[joernheissler]

Why does Ristretto255Scalar allow native Python types to do scalar math in the field? From my perspective that seems to have very little advantage in exchange for a lot of dangerous complexity. Do you have a specific use case that makes this desirable?

I feel that it's actually useful. But looking at the examples that I already wrote, somehow I don't use it. Only place I actually did use Fractions and ints is with scalar multiplication on points. I'll remove that convenience feature in the scalar field and explicitly allow int+Fraction in Points.

[reaperhulk]

I'm pretty negative on allowing other Python types to interact via infix operators with points (or scalars) absent a compelling counterargument. Why not just have users create additional points and use those points to perform mathematical operations?