There were initially two motivations to separate Scalar types:

1. According to RFC 8032 Ed448 key encoding should have 57 bytes.
2. hash2curve::FromOkm could only be implemented once on the Scalar type, setting the length regardless of the curve.

We solved 2. in #1391.

I would like to get rid of the 1. motivation as well by just not following RFC 8032 here. The RFC has a specific encoding for signing keys that involves using SHAKE256. This seems quite unnecessary to me and would make encoding/decoding EdwardsScalar quite expensive.

Therefor I propose that we differentiate between scalars and signing keys, which we already do via ExpandedSecretKey internally on our own SigningKey already.

In conclusion: we can merge the Scalar types back together again and they will all have a 56-byte encoding. Ed448 signing keys will not be affected and point serialization formats won't be affected.