Currently these aren't tested; Sage gets unhappy working with isogenies of
large elliptic curves.  (Also, the previous test vectors were generated just to
test curve arithmetic, so they're not in the correct isogeny class and should
be changed...)

This contains Montgomery (pseudo)addition, doubling, and tripling.

The formulas are slightly amended from the usual Montgomery arithmetic to allow
projective curve coefficients.

Having operators return pointers to the recievers makes it possible to chain
operations.

The implementation is a basic sliding-window with a series of hardcoded values
for how many times to square and what to multiply.

Split the field arithmetic code into three types:

- ExtensionFieldElement :: represents an element of F_{p^2}
- PrimeFieldElement :: represents an element of F_{p}
- fp751Element :: internal type holding an element of F_{p}

The difference between PrimeFieldElement and fp751Element types is that the
PrimeFieldElement assigns a particular interpretation (Montgomery form) to its
data, while the fp751Element doesn't.

Add a function to perform "strong reduction": given an element in [0,2*p),
reduce to an element in [0,p) in constant time.

In order to have an assembly-implemented function operate on some data, it's
necessary to pass pointers to the data into the assembly implementation.
However, Go sees a pointer to some data passed into a function, and cannot
prove that the function does not keep pointers to that data.  It therefore
assumes that the data escapes the local scope, and moves it onto the heap.  To
avoid allocations in the hot path, instead mark the functions with
//go:noescape, which instructs the compiler that the inputs don't escape.