primefield: add FieldExt

[tarcieri]

Also bounds PrimeFieldExt on it, adds it to the macro boilerplate, adds manual definitions where needed, and bounds the FieldElement type used by primeorder::PrimeCurveParams on it so it needs to impl it as well.

This follows from RustCrypto/traits#1997 where we were discussing how we could better leverage the various lazy field implementations we had.

In that thread I suggested we could avoid exposing separate field element types for reduced/unreduced operations and have a simpler abstraction for eagerly versus lazily reduced field elements if we supported various "fused" operations that are useful in dense field arithmetic, e.g. add-then-mul, mul-then-add.

For example the RCB implementation in primeorder could migrate to using the "fused" operations which start out backed by default impls which call the individual arithmetic ops which, where applicable (mostly k256 and p521 for now) can be replaced by optimized implementations which can avoid unnecessary normalization/reductions when performing these sequences of operations.

This adds a FieldExt with no methods despite the fact we already have a PrimeFieldExt. The idea is FieldExt is an extension trait for functionality that would otherwise go on ff::Field, and PrimeFieldExt is an extension trait for ff::PrimeField, which in this case due to how the ff crate factors the relevant operations happens to be dealing with encoding, whereas FieldExt can have the "fused" arithmetic ops as ff::Field otherwise deals with the low-level arithmetic operations.

What's nice is we could stabilize it after adding this and worry about the specific arithmetic operations to add later so it doesn't block stabilization. I will follow up with a PR to propose some I think make sense looking at what sorts of operations appear frequently in RCB which remains the main candidate for these sorts of optimizations as it would improve point addition performance which improves practically every other point arithmetic operation.

[tarcieri]

PR to add some initial fused operations backed by p521: #1840