Having _BASEPOINT_TABLE and _BASEPOINT_POINT means that it's not possible to
use the slow, generic scalar mult in place of the fast, precomputed scalar
mults.
Split the field arithmetic implementations into `FieldElement`,
`FieldElement32`, and `FieldElement64`. `FieldElement` is a type alias for one
of `FieldElement32` or `FieldElement64`, depending on feature selection.
`field.rs` contains tests and code which is generic with respect to the
implementation (e.g., inversions), while `field_32bit.rs` and `field_64bit.rs`
contain the implementation-specific code.
The implementation is not completely hidden, since `FieldElement32` and
`FieldElement64` are tuple structs whose elements are public; `pub(crate)`
doesn't seem to work for tuple structs.
Similarly, the constants file is split over multiple files, depending on the
implementation.
This code isn't constant-time, but maybe should be. However that would
prevent a bunch of nice things (e.g., Option types). Probably good to
think about this.
Would be good to have the basepoint itself, but this doesn't seem possible: the
fields of an ExtendedPoint are not public, so we can't construct them outside
of curve.rs (by design, to prevent constructing invalid points). Maybe const
fn support could change this.
This was presumably added for use with formulas that use two multiplications by
small constants (i.e., 121665 and 121666) instead of one multiplication by a
large constant (i.e., -121665/121666), but we don't use those formulas.
