mnemonic.make_seed: add "extra_entropy" arg, and expose it to CLI/RPC

[SomberNight]

This is useful for the following threat-model:

The randomness generated by the CPU/OS is assumed weak, but otherwise the user trusts the CPU/OS to execute code as-is. The user can inspect the source code to see what they provide as custom entropy is used in a sane way.

As the extra entropy is simply XOR-ed in, into the OS-generated randomness, it cannot be used as a footgun.

Note this significantly differs from the old custom_entropy option [0] that existed between version ~2.0 and 3.1.2 [1]:

• the old option replaced the OS-entropy with the user-provided entropy
  • e.g. if the user provided what looked like 64 bits of entropy, and by default we wanted to create a 132 bit seed, the resulting seed only used 132-64=68 bits of os.urandom()
  • hence I think the old option was a footgun -- it required expert knowledge to use properly
  • instead, the new option mixes the user-provided entropy with os.urandom(), in a way that can never make the result have less entropy
• with the old option, the "custom_entropy" arg was an int, of which every "bit" was used as-is
  • for example, if the user wanted to provide some dice rolls, e.g. "6 3 5 2 6 6 2", and they passed the int "6352662" (base 10), they lost a lot of entropy by not using high decimal digits - i.e. the user was required to know how to convert their entropy to the expected format (e.g. dice rolls as base6, and then convert to base10)
  • instead, the new option takes an arbitrary string, which is then hashed internally, hence it is not possible to misuse the API
    • e.g. it is safe to provide dice rolls as a string, e.g. "6 3 5 2 6 6 2" or "6352662" or in any imaginable way
• the old option exposed a "check_seed" CLI command, that could be used to verify the user-provided entropy was used as part of the seed-generation. This is not possible with the new option.

closes https://github.com/spesmilo/electrum/issues/523

[0]: https://github.com/spesmilo/electrum/blame/883f9be7d15cf1aba16895a0848f0d7af99f2ff3/lib/mnemonic.py#L149 [1]: 5e5134b76ffec8ed9702f5661a1d16e9e52a24c8

[SomberNight]

@ecdsa in https://github.com/spesmilo/electrum/commit/5e5134b76ffec8ed9702f5661a1d16e9e52a24c8 you wrote you removed the option as it was redundant with seed extensions. With the threat model stated in the OP, I think that argument does not really apply:

• as then if they don't trust the CPU/OS for entropy they might as well just use an "empty" seed (e.g. the 9dk seed in practice) with a very long passphrase
  • which is a bit ridiculous, and also makes the backup process error-prone

Note that the passphrase can obviously still be used in addition this, they are not redundant at all. For example, the passphrase can be used as a counter, to create "accounts" for the same seed. Or "hidden" wallets. etc.