Scalar::pow not ergonomic between two Scalars

[Wassasin]

Exponentiation between two scalars is currently difficult because exponentiation is implemented as fn pow(&self, by: &[u64; 4]) -> Self. Whilst Scalar::to_bytes converts to a little endian byte encoded integer, it is not directly usable for pow as it does not yield an array of [u64; 4].

Consider adding a variant of pow that directly accepts Scalars.

[ebfull]

Perhaps instead we could implement From<Scalar> for [u64; 4].

[CPerezz]

That implementation will apply the montg. reduction I assume no?
Since it will probably be the opposite of:

pub const fn from_raw(val: [u64; 4]) -> Self {
        (&Scalar(val)).mul(&R2)
    }

We could mabe call it as_raw or something similar to be clear in respect of the application of the montgomery reduction to the Scalar before returning the array.

What about implement pow taking a &Scalar and apply the montgomery reduction iside?

[str4d]

For the pow_vartime() API in the ff crate, I've generalised it to accept both &[u64] and &[u8]; once bls12_381 implements the ff traits, that can be used here.

It might still be useful for it to also accept same-typed field elements (or perhaps elements implementing a specific ScalarField trait), because the encoded representation of a scalar is not guaranteed to be the endianness that pow requires. For the same reason that we aren't specifying the endianness of PrimeField::Repr, I'm dubious that we want From<Scalar> for [u64; 4] in generic code; instead we'd either want a specific endianness-tagged method, or enable field elements to be exponentiated by themselves (which keeps the endianness an implementation detail). The main decision then is about what the ergonomics should be - it does not make sense for elements of arbitrary fields to be exponentiated by each other, but it does make sense for fields specifically used to represent scalars.