`ed448-goldilocks`: merge `*Scalar` types and forego RFC 8032 encoding

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.

Start by reviewing the Scalar and EdwardsScalar types, the hash2curve::FromOkm implementation from #1391, and the existing SigningKey/ExpandedSecretKey handling. Determine how to merge the scalar types with 56-byte encoding while preserving Ed448 signing-key and point serialization formats; RFC 8032 is the relevant encoding reference.