Differences in sr25519 implementations in JS and rust

[ameba23]

This relates to this crate using schnorrkel's SecretKey::from_ed25519_bytes when creating a sr25519 keypair from a given secret key.

It seems this is needed due to the different way sr25519 keypairs are created in @poltadot/keyring and sp-core::sr25519.

See the discussion in this PR:
#12

@frankiebee found this open issue in the schnorrkel repo where someone else has found this discrepancy: w3f/schnorrkel#77

@frankiebee also found where this from_ed25519_bytes gets used in polkadot's wasm-crypto which is called internally when sr25519 signing using @polkadot/keyring:
https://github.com/polkadot-js/wasm/blob/b82e28ad4ed888ef4a461ee8e0ba25acdb87dc1a/packages/wasm-crypto/src/rs/sr25519.rs#L125

TLDR: sr25519 Signing is not the same in polkadot-js and either of the substrate rust implementations (sp-core::sr25519 and subxt-signer). The public key included in a SignedMessage created with encrypt_and_sign is different to the corresponding public key when creating a keypair in any sr25519 implementation, or with SignedMessage::new.

Do not use encrypt_and_sign or decrypt_and_verify from rust.