Simplify ECDSA module structure

[marsella]

Right now, there are two ECDSA implementations in the repo. One uses the curves implemented in Common/, and one defines all the legal curves in the same module as the signature implementation.

In general, we need to figure out what the differences are between these two implementations. But for now, it would help to more cleanly separate the implementations of the curves from the implementations of the signature scheme.

To do so, I propose adding an interface that lists out the curve operations required to execute ECDSA. This won't be a fully generic EllipticCurve interface (since that's a very hard problem) ~and for now it won't even be generic over prime-order Weierstrass curves (the NIST-approved curves for ECDSA, see SP 800-186 Table 2). It'll just be a list of the operations we need to execute ECDSA. Then we can parameterize the ECDSA implementation using the new interface and get a bit of separation between the curves and the signing.~ After more careful review of the requirements for ECDSA and ECDH, I decided that we should just have a generic version of prime-order short-weierstrass curves, since almost all the non-deprecated curves for all the specs we want to implement fall under that category[^bp].

[^bp]: There's an important difference between the NIST-standardized curves and the brainpool curves, which are also approved. All the NIST algorithms are optimized for curves with a=-3 but the brainpool curves don't have this restriction, I think. If we want to expand support to the brainpool curves later we'll have to refactor to actually have an EC interface that can be instantiated by either bp or nist curves, then parameterized by the appropriate parameter sets. But I think that's a problem we can address later.

~My expectation is that once the curves and the signatures are separated, and perhaps once we start implementing ECDH, we can figure out whether there's a better, more general interface for curves that would be useful in a wider variety of algorithms.~ Now my expectation is that we will do this in several PRs. First:

• [x] Define a reasonable prime-order elliptic curve interface - see #96.
• [x] Port the tests on elliptic curves from ecdsa.cry to the interface.

Then:

• [x] Update one of the ECDSA implementations to use the new interface
• [x] Add instantiations of ECDSA for the interesting curves
• [x] Make a tests directory for ECDSA that includes test vectors from the specs

Finally:

• [x] Clean up all the remaining elliptic curve and ECDSA implementations (see #119)

[marsella]

Okay, after some continued exploration, I determined a few things:

• There are 2 different ECDSA implementations
• There are 4 different implementations of prime-field short-Weierstrass curves (the P-suite approved for ECDSA)
• The PFEC curve interface is probably the closest in design to what I would've done; it's not currently used by either of the ECDSA implementations.
• I think the P-suite is the primary set of curves that we need to support right now; making an interface that's generic over more classes of curves does not seem like a good use of time

So I'm going to break up this issue into a couple of PRs:

1. Update PFEC to be spec-adherent and to contain all the routines needed for ECDSA (scalar multiplication, twin multiplication for efficiency, conversion between affine and projective representations)
2. Update one of the ECDSA implementations to use the PFEC interface (or make a new one; it depends on what's most efficient)

Other follow-up tasks will include: review the other EC implementations, take what we want from them and delete the rest. Reveiw the other ECDSA implementations and figure out how they're different and if it would be useful to keep them; delete if not.

[marsella]

We've now addressed all of these tasks! Closing as completed.