Improve points being used in data structures

[burdges]

In multi party protocols, there are situations where indexing some data structure with a public key comes in handy, so this adds various #[derive(..)] to CompressedRistretto.

In addition, this adds a RistrettoBoth both convenience type, which requires extensive boilerplate itself, but makes it easy to keep compressed and uncompressed forms together. If used properly, I believe RistrettoBoth should reduce implementation errors, improve readability, simplify indexing data structure, and maybe facilitate performance improvements like dalek-cryptography/ed25519-dalek#61

In essence, RistrettoBoth acts like a CompressedRistretto that drags around RistrettoPoint, which you access by calling .as_point(). I therefore did not implement constant time or arithmetic operation traits for it, but..

[hdevalence]

Thanks for this PR.

The additional derives for CompressedRistretto might be reasonable, and it would be good to have them in a separate PR based off of the current develop branch for discussion just for those. (I would like to think about what it means for us to advertise a point as being Ord, for instance, before merging it).

I'm not sure if we want to add the RistrettoBoth API. In the next few months, I'm planning to update and merge the code I wrote that provides a precomputation API (#125), which might supersede the precomputation use-case, and I'm not sure it's better to allow API clients to not think about the serialization/validation operation. For Ed25519, it makes sense to factor the public-key decompression into the PublicKey struct, but this might not be the case for other protocols, and in our Bulletproofs implementation, we arrange the code so that we don't need to maintain a pair of points.

[burdges]

Cool. Yeah cosmetic things like this should wait until any relevant developments get sorted out. :)

Yes, it's true protocol implementors could simply accept RistrettoBoth types instead of creating their own public key type, which should often have an error type with deserialization errors, like Ed25519, but the protocol implementor can reason about the deserialization failures better than users. In principle implementors can abuse RistrettoPoint similarly though, so at least RistrettoBoth gives a venue to explain this worry.

[hdevalence]

It might be a good idea - if it ends up being useful in a bunch of libraries that use curve25519-dalek, I wouldn't be opposed to adding it, I would just like to wait on it.

[burdges]

There is a minor mistake in the PartialEq and Eq definition for RistrettoBoth here, probably either they should be derived, and thus compare the point too, or else the fields should be kept private to the module.

[burdges]

I increasingly find this "both" approach slightly distasteful. It might be best to provide a both type but actually use some trait so that deserialization can be delayed until optional_multiscalar_mul. I originally considered using a trait that worked for multiple stages of being decompressed to be too much magic but maybe it's fine.