Refactor code not to use unescorted ed25519 secrets

Closes #798 (closed).

per that ticket, we don't want to have any ed25519::SecretKey or ed25519::ExpandedSecretKey instances floating around without their accompanying public keys. Otherwise, there is a risk that we would sign the same message using the same secret key with two different public keys, and expose ourselves to a nonce reuse attack.

Fortunately, all of the functions that we had to change incompatibly are behind experimental features.