Add hardened account support for VSPs

[jrick]

This commit adds a new account type for supporting the next VSP API.
The account is only used to derive hardened keys (so private keys may
be shared with external services). The account key is derived with
the path:

m/44'/cointype'/child/0'

This path is used because the cointype keys are already stored
(meaning users will not need to reseed to derive these accounts had
they not been derived off the BIP0044 cointype). Use of the
non-hardened derivation off the cointype key is done to avoid clashing
with the BIP0044 keys (which use hardened derivations only). The
hardened derivation following this is performed so that if any of
these keys are compromised, it will not result in the compromise of
other hardened purpose accounts.

The non-hardened child derivations off the cointype key begin at 0 and
are incremented for each created hardened account. New hardened
accounts may be created with the createhardenedaccount JSON-RPC
method.

A new account format in the database is used to record these accounts.
This format moves all account data fields that can change over time
(such as the account name and last returned child indexes) to a
variables bucket keyed by the account's uint32 identifier. Static
fields that never change for the account are recorded once in the
account row and never modified again. This change is being made (vs
saving all fields in the account row as is done for all other account
types now) to avoid needing to rewrite and duplicate fields as no
longer does the entire account row need to be rewritten. It's planned
to move the remaining accounts to a similar system in an upcoming
change and database upgrade.

To avoid needing to replace the usage of uint32 identifiers for every
account, the high account numbers (in the same range as imported xpub
accounts) are used for hardened accounts. The account row must be
checked in the database to determine whether an account with an
identifier in this range is a hardened account or imported xpub
account.

Because the hardened account only derives hardened keys, the wallet
must be unlocked to derive addresses for the account, and (like
BIP0044 accounts) the wallet must be unlocked to initially create the
account.

---

Note to reviewers:

• Backup your db before testing as this contains a database upgrade.

[alexlyp]

Small nit.

tACK for non-vsp wallet functionality. createhardenedaccount works as expected and can get addresses as per usual.

[jrick]

The UX for hardened accounts is significantly different enough, and its primary usecase (sharing private keys for voting rights with a VSP) can be handled with non-hardened accounts and a warning about revealing parent xpubs. I'm closing this PR and will refactor it to keep the database upgrade which adds the account variables that future work builds on top of.