Got leveldb into project & makefile, started test
Progress learning about leveldb...
Not only does it the test scan work, damned fast!
Not exactly right, but full scan in 8.9s !?!
Working balance/UTXO list (double scan) in 13s!
Added the PayloadHeaders class for PyMessage
Started filling in the levelDB wrapper
Merge branch 'leveldb' into ramreduceleveldb (mostly)

Conflicts:
	armoryengine.py
	cppForSwig/BlockUtilsTest.cpp
	cppForSwig/Makefile
Started a new proxy class for LevelDB/multimap ops

I'me hoping that the proxy class will be allow me to define identical
operations for both the multimap<> (RAM) solution and the LevelDB (HDD)
solution.  A simple preprocessor would let you switch between them at
compile time.

It's definitely more complicated than just updating the code directly to
use LevelDB... But it may be worth it in the long run.
Lot of supporting methods implemented for LevelDB transition

Haven't actually updated parseEntireBlockchain, readBlkFileUpdate, or
any of the get____() functions yet.  Plenty left to do (and test!).
Butchering the code even more...
Destroyed everything, piecing it back together....
Closing in on a prototype of persistent data...
A lot more to update than I thought...
This is becoming too involved for a partial upgrade

I think the solution is to not do a partial RAM-reduction update.  I
will just do the full Armory-maintains-its-own-blockchain, all at once.
However, that is lower on my priority list, so I'm going to go back to
the new wallet for now, and come back to this later.
Started figuring out how to manage bitcoind
Making progress on async bitcoind communication...
Getting ready to start testing bitcoind manager
I can't believe the SDM actually kinda works!

(Linux) It successfully creates the datadir, finds bitcoind, starts
the process, then monitors it and returns reasonable getSDMState()
values.  It fully sync'd testnet in a few minutes and looked like
it was ready to go!

There are still some issues needing to be fixed -- such as sometimes
it doesn't shutdown the process when Armory exits.  Probably a simple
Popen arg for that.  Also, will need to figure out file permissions
on Windows so that I can safely create a bitcoin.conf file for new
users that don't have one yet -- but it must be set with strict
permissions or it could open up a security hole!

The proof-of-concept is done.  Just gotta grind through the rest...
Taking picobit's suggestion, created guardian.py

It's very simple, but seems very powerful.  The idea is that when Armory
starts bitcoind in a subprocess, there's no guarantee bitcoind shuts
down when Armory hard-crashes (killed, segfault, etc).   However, once
it is started, Armory can grab its own pid, and the pid of bitcoind and
pass it to a separate "guardian" process.  If Armory doesn't shut down
bitcoind, it won't shut down the guardian either ... which will shutdown
bitcoind and then itself if it detects that Armory closed.