mul_bits_be endianess footgun

[elichai]

Until recently all the Scalar APIs are little endian based (Scalar::from_bytes_mod_order_{wide}/from_scanonical_bytes/from_hash/hash_from_bytes/{to/as}_bytes)
The same is true for raw scalars in the MontgomeryPoint API: MontgomeryPoint::mul_{base}_clamped.
But the new MontgomeryPoint::mul_bits_be uses Big Endian.
On one hand, this is pretty clear in the name of the function, on the other it is not clear on the rest of the functions,
So someone might naively think they can replace MontgomeryPoint::mul_clamped(bytes) with something like MontgomeryPoint::mul_bits_be(bytes.into_iter().flat_map(|byte| (0..8).map(|i| (byte >> i) & 1 == 1))), which is obviously incorrect.

Should this be renamed to mul_bits and use LE order? should we also add mul_bits_le? Or are we OK to leave it like that because it's a "hazmat" function anyways?

[tarcieri]

I'd note mul_bits_be already has a rather large warning on it. I'm not sure there's much that can be done other than adding a replacement and deprecating it?