zcash_client_sqlite: Integrate "is relevant seed" logic into database migration

[str4d]

The mobile SDKs require the ability to check whether a given seed is relevant to a database, before using the seed with the database. This was initially added via a WalletRead::validate_seed method (that validates the seed against a specific account, requiring some non-trivial logic to convert this into a "relevant to any account" check). However, in the context that the mobile SDKs need it, this method has a circular dependency:

• The caller wants to choose which seed to use (or enable its users to provide a seed), and confirming the seed is relevant requires querying the accounts table.
• !uerying the accounts table requires that the table has been fully migrated.
• Migrating the accounts table can require the seed, and currently does after the recent AccountId changes.

This gets more complicated once accounts derived from multiple seeds can coexist in the wallet DB, but we fortunately don't have to solve that problem yet because the migration API currently only takes a single seed, and the seed-requiring migrations return an error if the given seed doesn't match every derived account.

To solve this for the mobile SDKs (and single-seed users more generally), we will change the migration logic to always check that the seed is relevant to at lesat one account, instead of only doing so when a migration runs that requires the seed. The error returned from this new logic will be unified with the "wrong seed" errors returned from the seed-requiring migrations.

After these changes, a caller that has some database (e.g. from a backup) and a candidate seed can then do the following:

• Attempt to migrate the database without any seed.
  • If the migration requires a seed, attempt to migrate the database with the candidate seed.
    • Caller gets an error if the seed is not relevant to the database.
    • If the migration succeeds, then the candidate seed was relevant to the database.
      • Right now, the caller "knows" that this is the only seed relevant to (the derived accounts in) the database. In future this won't be the case, but that's out of scope for this issue.
  • If the migration succeeds without any seed, call their respective isSeedRelevantToWallet logic (which internally calls WalletRead::validate_seed) to check the candidate seed (and any other candidates).
    • Given that I'm making changes, I will probably just replace WalletRead::validate_seed with WalletRead::is_seed_relevant_to_any_derived_accounts.

This isn't the prettiest UX for downstream users, but it's the simplest we can get working for Zashi 1.0 that doesn't require us to build and maintain self-introspecting queries that need to be valid for every possible accounts table migration state.