Add support for 64-bit moduli

[dvdplm]

The tiny-curve crate uses 64-bit FieldBytesSize, and when used in combination with the FromEncodedPoint trait, there's a problem with a missing impl of the ModulusSize trait.

Adding U8 to the list of impl'd types should fix this.

[tarcieri]

Ugh, not super wild about this. Generally the whole elliptic-curve stack has a minimum field size of 192-bits by design.

[dvdplm]

Could moving it to a hazmat module make it less yucky? The "safe" sizes could be re-exported backwards compatibly.

[fjarri]

Ugh, not super wild about this. Generally the whole elliptic-curve stack has a minimum field size of 192-bits by design.

Is this kind of hand-holding really needed? It's still pretty easy to make an unsafe curve even with 192-bit elements.

[fjarri]

Also, in case this misuse protection was not the primary purpose of ModulusSize, a viable alternative is to remove the bound on ArrayLength and instead add an associated type:

pubtraitSec1Sizes{// or whatever nametypeModulusSize:ArrayLength<u8>;typeCompressedPointSize:ArrayLength<u8>;
...
}

I don't think it will restrict any current upstream usage, but it will allow one to define their own ModulusSize if needed. Currently it's not possible since ArrayLength implies typenum::Unsigned, which is sealed.

[tarcieri]

@fjarri I'd be fine with some way of letting crates define their own downstream SEC1 size combinations if it can be made to work with the elliptic-curve crate

[fjarri]

Seems that Sec1Sizes approach will cause quite a bit of changes, so as a minimum-change option I made an experimental PR that just implements ModulusSize for all typenum types: #1650.

[tarcieri]

Let's go with #1650