Design for importing FVKs, IVKs, and even Unified spending keys

[AArnott]

As discussed on discord, use cases exist for importing accounts with spending or viewing keys into a Zcash application (e.g. a wallet, or POS machine) that are unrelated to a seed phrase, or possibly related to a seed phrase that does not equal the seed phrase the wallet was initialized with.

Some example use cases:

1. Importing a UFVK so a user who wants to monitor a cold wallet via a full viewing key from his/her hot wallet app.
2. Multiple seed phrases so a user that already has multiple seed phrases across various wallets can control them all from one app.
3. Import unified spending keys for an enterprise can create a seed phrase which the CFO keeps confidential, but uses the seed phrase to create accounts that he/she assigns to various departments or individual stores. These accounts would be shared via unified spending key so as to keep the seed phrase confidential.
4. Importing an IVK at a Point of Sale machine at a store needs to generate diversified addresses and see incoming transactions that it can associated with those generated addresses so the clerk can confirm products are paid for.

The zcash_client_sqlite crate's table schema assumes exactly one seed phrase, and all accounts are spending accounts based on that seed phrase. According to the discord discussion, this assumption may have impacted the design and code of the zcash_client_backend crate as well.

Let's start the discussion by identifying which of the above use cases may fit into these crates named above, and which ones are definitely out of scope such that that use case can only be addressed by forking or relying only upon the lower-level crates and recreating some of the same functionality that the zcash_client_* crates have.

[nuttycom]

Related to Electric-Coin-Company/zashi#55