Replace repeated integer literals with constants

[tarcieri]

I think it would be good to add some more constants in places where integer literals are frequently repeated, and ideally establish a naming pattern that can be reused across types/backends (and also shared by ed448-goldilocks, ideally). Some examples:

• 32 is used all over the place (along with [u8; 32]) as the serialized size in bytes of a compressed coordinate, either an Edwards y-coordinate or a Montgomery-x/u coordinate.
• The number of limbs and number of bits-per-limb in the unsaturated representations of field elements, e.g. 5 and 51-bits for the 64-bit field implementations, with up to a 54-bit capacity (cc @kayabaNerve)

In particular I'd like to see [u8; CONSTANT1], [u32; CONSTANT2], [u64; CONSTANT3] in places where there are currently [u8; 32], [u32; 10], and [u64; 5], and e.g. loops bounded on constants instead of integer literals. Perhaps we could come up for type aliases for e.g. [u8; 32] that's frequently found in the external API.

For ed25519-dalek perhaps we could migrate some of the freestanding constants like PUBLIC_KEY_LENGTH and SECRET_KEY_LENGTH to inherent constants like SigningKey::LENGTH or SigningKey::SIZE.

[kayabaNerve]

While I support associated constants, I'll note [u8; 32] is already one via the PrimeField, GroupEncoding APIs. While those are optional, continuing to support traits and integrate them should naturally cause this.

See the LazyField trait where it declares how much capacity it has, even if it doesn't describe its limb arrangement at this time.

[tarcieri]

We can do both, and have a type alias which is used to define the associated type

[kayabaNerve]

Of course :) Just noting how this is naturally occurring.