[WIP Preview] New secure hierarchical deterministic wallet address manager.

This pull request is a work in progress and is being opened as a preview.  It implements a new secure, scalable, hierarchical deterministic wallet address manager.

The following bullets are an overview of what is already supported:
- BIP0032 hierarchical deterministic keys
- BIP0043/BIP0044 multi-account hierarchy
- Strong focus on security:
  - Fully encrypted database including **public** information such as addresses as well as private information such as private keys and scripts needed to redeem pay-to-script-hash transactions
  - Hardened against memory scraping through the use of actively clearing private material from 
memory when locked
  - Different crypto keys used for public, private, and script data
  - Ability for different passphrases for public and private  data
  - Scrypt-based key derivation
  - NaCl-based secretbox cryptography (XSalsa20 and Poly1305)
- Scalable design
  - Multi-tier key design to allow instant password changes regardless of the number of addresses stored
  - Tests have been performed against a sample database with 1 million addresses in it with no degradation in performance
  -  It currently takes about 1.5 seconds per 1000 new addresses generated on commodity hardware
- Import WIF keys
- Import pay-to-script-hash scripts for things such as multi-signature transactions
- Ability to export a watching-only version which does not contain any private key material
- Programmatically detectable errors, including encapsulation of errors from packages it relies on

Things left before it's ready for merge:
- Implement address synchronization capabilities
- Add full test coverage
- Add examples
- Add README.md
Good catch in the missing re-locks.  I've updated this to ensure it's re-locked on all paths, however I didn't use the named returns and defer approach because that is way too easy to hide mistakes through shadowed errors.

Missing re-locks are fairly obvious to anyone reviewing the code as evidenced by you noticing them missing.  However, it's much harder to notice shadowed errors which wouldn't set the named error and therefore would cause it not to be locked.  We've had this happen several times in the past when using named variables, so I highly prefer to avoid idioms which lead to hard-to-detect bugs.