* Further simplify "constructor" function's allocation of structs
* Fix formatting

* Allocate with composite literal instead of new
* Remove check of number of bytes read from rand

* Remove flags field from key struct
* Change JSON struct fields from string to []byte
* Change GenerateNewKey API to take io.Reader for random source
* Remove mixing entropy source function
* Use testing Fatal in tests

* Simplify scrypt constants with const block
* Add key store constructors and make their types private
* Simplify key store and file namings to be less Java Enterprise™
* Change test error logging to use t.Error(err)
* Reduce number of naked returns (just like my ex-gf)
* Simplify file reading path code

* Add new generic key_store interface
* Add new plaintext key store storing unprotected keys on disk
* Add new encrypted key store storing encrypted keys on disk
* Add new entropy mixing function using OS and go runtime sources

* Whisper protocol wasn't properly suppling envelope slices
* Message history wasn't properly propagated
* Added 'Messages' method, filtering any current envelope with the
  supplied filter.

JitVm struct stub. Forwards calls to DebugVm.

* proper 0xhex
* filters fixed
* start of filter manager
* accounts for ws. Closes #246

- the spec says response to getBlockHashes(from, max) should return all hashes starting from PARENT of from. This required major changes and results in much hackier code.
- Introduced a first round block request after peer introduces with current head, so that hashes can be linked to the head
- peerInfo records currentBlockHash, currentBlock, parentHash and headSection
- AddBlockHashes checks header section and creates the top node from the peerInfo of the best peer
- AddBlock checks peerInfo and updates the block there rather than in a node
- request further hashes once a section is created but then no more until the root block is found (so that we know when to stop asking)
- in processSection, when root node is checked and receives a block, we need to check if the section has a parent known to blockchain or blockPool
- when peers are switched, new peer launches a new requestHeadSection loop or activates its actual head section, i.e., the section for it currentBlockHash
- all tests pass