Consistent alternative to `PrimeField::to_repr`

[tarcieri]

I wanted to make a companion issue on this repo to this one here: zkcrypto/group#78

Notably the wNAF implementation there assumes to_repr always returns little endian. There may be changes necessary here so it's possible to consistently iterate over the bits of a scalar in little endian order, and I just wanted to make sure that got considered before a release.

FWIW we're doing this hack in @RustCrypto for now, which it would be great to get rid of so we can migrate to the upstream ff: https://github.com/RustCrypto/ff/pull/10

[TalDerei]

fixing downstream group LE assumptions on an agnostic ff trait seem like an idiomatic release target. we could have an iterator over bits in LE order (independent of to_repr encoding), or suggesting just a second dedicated serialize that returns LE bytes and group can derive the LE bit iteration. the former is more targeted, but the latter is simpler imo (byte level API over bit level one). what if we just included to_le_repr on PrimeField as a provided trait method, which closes the assumption gap you flagged?

[str4d]

We avoided exposing any specific endianness on the Field and PrimeField traits, so that generic users of them would not assume any particular endianness about their opaque encodings. This was in part to avoid encouraging or accidentally creating any mixed-endianness environments, where the standard endianness of a particular field's representation is used in some places, but the opposite one is used in others, within the same protocol and without the implementor's intention (potentially not noticing until the protocol was deployed and it was too late to fix). In particular, if a generic protocol is written initially using a field with a little-endian encoding, the protocol implementer would not notice the problem until someone instantiated it with a big-endian field.

For that reason, I strongly oppose adding a PrimeField::to_le_repr method. I would be maybe open to a to_le_bits or something that does not return Self::Repr, but I'd prefer if we could find another approach where specific-endianness methods were encapsulated by a different trait. Perhaps one designed for the use cases it enables, in particular the wNAF implementation in group - maybe the trait should live there?

[tarcieri]

@str4d something like to_le_bits sounds good to me, depending on how it's implemented

[kayabaNerve]

In my work, I need both the *-endian representation of field elements and the modulus. Can we please not forget about char_le_bits?

EDIT: Never mind, as I have remembered I can (and already sometimes do) simply encode -1 and then add 1 to obtain the modulus.