Derive additional traits for CompressedRistretto / CompressedEdwardsY

[hdevalence]

Branching off of #220, specifically 3e91ba0 , where @burdges suggested adding

#[derive(Ord, PartialOrd, Hash)]

to CompressedRistretto. This allows using a CompressedRistretto as the key to a BTreeMap, which requires Ord (hence PartialOrd), and with HashMap, which requires Hash.

This seems like a useful use-case, for instance looking up information by a public key.

Some questions that would be good to cross off answers to:

• Does it make sense to derive Ord for encodings of points? Unlike scalars, there's no meaningful ordering on points, so we could only do something like ordering the bytestrings.

• Does it make sense to do this also for CompressedEdwardsY as well as CompressedRistretto? In particular, is there any potential for ambiguity/non-uniqueness?

• Is there a problem with using the derived implementations? For instance, if we derive Hash, will it do something like hash one byte at a time?

• What's the stability impact of adding new derives? I think this is probably fine (it's just adding new traits) but we should check.

[burdges]

I never suggested this for CompressedEdwardsY out of anti-cofactor prejudice, but actually the cofactor could be managed reasonably for at least multi-signatures, so sure whatever.

I think these derives produce very thin wrappers, so the question boils down to [u8;32]:

In this case, impl Hash for [T; 32] delegates to impl Hash for [T] which uses <T as Hash>::hash_slice, for which u8 does the right thing.

Also impl PartialOrd for [T; 32] delegates to impl PartialOrd for [T], which used SlicePartialOrd and SliceOrd

[hdevalence]

Closed by #318.