Add mnemonic support

[palas]

Changelog

- description: |
    Added support for generating mnemonics and for deriving payment and stake keys from mnemonics.
  type:
  - feature

Context

Depends on release of cardano-addresses (IntersectMBO/cardano-addresses#279)
Allows IntersectMBO/cardano-cli#975.

How to trust this PR

I would look at the tests. The hard-coded tests have been checked against existing wallets.
I have also tested that the derivation works by doing a prototype command in the cardano-cli.
Make sure you like the changes to the API. I have tried to keep them minimal.
Probably the most controversial bit are the instances I added, but they are not exposed. The reason I parametrised the index type is that for some types of keys that I haven't added yet (because I am waiting for a cardano-addresses release) the payment is not necessary, so I plan to set it to () in those.
Also make sure the documentation is good enough.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. See Running tests for more details
• Self-reviewed the diff

[Jimbo4350]

I made a first pass. I want to look at it again before approving.

[carbolymer]

LGTM. I'm leaving approval to @Jimbo4350

[Jimbo4350]

This LGTM however I think it may be better as two different type classes so we can avoid using () and an associated type.

What do you think about class SigningKeyFromRootKey keyrole and class IndexedSigningKeyFromRootKey keyrole?

After we decide on this, clean up the commit history 👍

[smelc]

This LGTM however I think it may be better as two different type classes so we can avoid using () and an associated type.

While I salute the effort to keep one interface that you did @palas, I agree with @Jimbo4350's suggestion here. I think it'll make the API clearer.

Also big kudos on the large amount of documentation written in the new code 👏

[palas]

@Jimbo4350 @smelc So we would need two functions right? Another option I considered was having an algebraic data type as a parameter with all the info. Let me know if you prefer that.

[Jimbo4350]

@Jimbo4350 @smelc So we would need two functions right? Another option I considered was having an algebraic data type as a parameter with all the info. Let me know if you prefer that.

I think two separate classes is better here.