Add support for sr25519 accounts

[oasisprotocol]

Add support for sr25519 accounts

[kostko]

I wouldn't support any of the interoperability stuff for now as there does not seem to be a clear use case. Implementing only the simplest correct scheme (compatible with Ledger) for now makes the most sense.

[matevz]

I did some research today how Polkadot uses sr25519.

Key derivation:

• they do not use standard bip32 derivation, but their own substrate derivation obtaining "soft" and "hard" keys.
• I tested Enkrypt and Polkagate wallets and they derive the same substrate addresses for the given mnemonic.
• Ledger's Polkadot nano app (developed by Zondax) do not implement substrate, but a bip44-like derivation using m/44'/354'/account'/0'/0' path. This gives incompatible addresses with Enkrypt and Polkagate.
• Importing Polkadot accounts is done via .json files or the mnemonic. No "Enter private key:" fields exist in the wallets.

Addresses:

• Polkadot addresses use Base58 encoding.
• Three types of addresses based on the prefix: Polkadot (0), Kusama (2) and Generic Substrate (42).

For better interoperability with Polkadot, I suggest we split the sr25519 work into:

• use Polkadot derivation path library (and add new account type sr25519-substrate?)
• use the ledger's way of deriving the account (PR #76, sr25519-bip44?)
• define Polkadot -> Oasis address mapping (similar to what we did for ethereum)
• show sr25519 addresses in Polkadot's Base58 format
• support importing Polkadot wallets from JSON-encoded export file (I think this eventually generates sr25519-substrate type then)

[matevz]

Implemented in #119