Microcontroller optimizations.

I have a rather fast implementation of the base field for Cortex-M4/M33 microcontrollers, wrapping stealing the assembly routines in https://github.com/Emill/P256-cortex-ecdh/blob/master/P256-cortex-m4-ecdh-speedopt-gcc.s. Would there be interest to include platform-specific arithmetic implementations in this crate, or should I focus on a "lean and mean" MCU fork?

Some complications are:

• use [u32; 8] for base field
• assemble routines and commit "binary" to repository (avoids need for assembler in dependent crates)
• pick implementation in build.rs, possibly overridable
• unit tests require a qemu-tests sub-library
• the use of proptest in dev-dependencies breaks the build for no_std due Cargo feature additivity (byteorder with default features, as so often), not sure how to fix this :/
• dev dependency hex is std
• I'm experimenting with inline assembly as well, which might be pulled in if compiled on nightly

This relates to other decisions as well, such as in https://github.com/RustCrypto/elliptic-curves/issues/54 whether to enforce correct but slow constant-time scalar inversion, or open the door to non-constant time implementations which might be abused.

Start by reviewing the proposed P256-cortex-m4-ecdh-speedopt-gcc.s routines and the repository areas mentioned for build.rs, qemu-tests, no_std dependencies, and inline assembly. The issue does not define a settled implementation path; done would require an agreed platform-specific arithmetic design, integration strategy, and tests for the supported Cortex-M targets.