elliptic-curve: affine y-coordinate access

[nickray]

Understanding the arguments pro/con coordinates from #817...

For a generic-ish Frost implementation, I have need to determine if the output of distributed keygen has even y-coordinate, to perform the Taproot adjustment. I can get away with a local AffineYCoordinateParity trait (fn has_even_y(&self) -> bool) that I implement on k256 and bound on, but maybe "for symmetry" it wouldn't be that horrible to add either AffineYCoordinate or at least AffineYCoordinateParity to the AffineArithmetic::AffinePoint bounds?

[tarcieri]

See this PR for some additional context: RustCrypto/elliptic-curves#50

[tarcieri]

Some discussion of solving this in the group crate: zkcrypto/group#30

[tarcieri]

#1237 has the best description of the current state of affairs and the evolution of these traits

[tarcieri]

Now that we've merged the ed25519-goldilocks crate into https://github.com/RustCrypto/elliptic-curves and people are also trying to impl the elliptic-curve traits in curve25519-dalek, I think it's become unavoidable that we expose the affine y-coordinate, as notably these curves serialize points in the form of a compressed Edwards y-coordinate.

The original goal was to avoid things like invalid curve attacks by exposing only compressed points, but different curves compress the coordinates in different ways, so it seems like adding the y-coordinate here is unavoidable.

Likewise, zkcrypto/group#30 hasn't gone anywhere in three years, so it seems we need to provide a solution.