Add support for importing accounts by UFVK

[AArnott]

Add import_account_hd and import_account_ufvk methods to the WalletWrite trait and implements them for the zcash_client_sqlite crate.

Also fix wallet::add_account to not fail when the UFVK contains fewer keys than librustzcash was compiled to support. For example, a UFVK that lacks a transparent key will no longer be rejected.

Partially fulfills #1075

Open questions

• The spending_key_available parameter declared by import_account_ufvk function isn't used at present. It's a future-proofing idea for an optimization that we'll surely want to leverage down the road. The open question is should we go to the trouble to record its value in the accounts table now, or only when we do the additional work to actually optimize that path?
• Eventually I'd like to add an API to import an account with only an UIVK. With that in mind, should we add another function later to import such an account, or should we promote the sqlite crate's ViewingKey enum for use by a more general import account function that takes the ViewingKey enum? Consider also that we may want the ability to import accounts by pool-specific keys (e.g. transparent private key, sapling private key, sapling viewing key, etc.) eventually too.
• Not entirely related to this PR, but it came up in my review: when zcash_client_sqlite::wallet::add_account rewrites scan ranges for the new account, could it possibly make the range to scan smaller than it already was? Say, for example, one account was fully synced. Then two new accounts were added together, the first with an old birthday and the second with a young birthday height. Would the older birthday with the broader scan range survive such that the next sync would scan enough blocks for the longer of the two?
• Whichever merges later (this or #1135), the error raised by code added in this PR if no UA can be created should be updated to not return a code indicating that a shielded receiver is required.

TODO

• Add tests
  • [x] Success: importing an account with a UFVK that does not conflict
  • [x] Failure: importing an account with an index that is already defined in the database.
  • [x] Failure: importing an account with a viewing key that collides with an existing view-only account
  • [x] Failure: importing an account with a viewing key that collides with an existing HD derived account

[AArnott]

I've manually tested this in my app and it works. I'd prefer to add unit tests to this PR only after I get a thumbs up on the API changes so that I know I'm testing the right thing.

[AArnott]

I rebased my commits and removed the merges (which brought back merge conflicts) so that I can use these same commits in my fork without bringing in the #1431 regression. Once approved, I can do a final merge with main to resolve conflicts.