add an explicit db.open() call which will provide the hook for passing configuration information into the db layer

basic testing of all db.js apis complete, also completed implementation of identitysync to check installed pubkeys.

consolidate db.checkAuth and db.checkAuthHash - move all bcrypt knowledge out of the persistence layer

tests of db.isStaged, db.stageEmail, db.gotVerificationSecret, and db.emailKnown.  also add some documentation in db.js for various apis

initial stubbing of db.js tests, also generalize db.js so that the path where the database resides may be configured

if you can verify an email, you can take ownership of it.  this should trigger some fun conversations with thunder. closes #36

move to bcrypt for password hashing and storage.  This satisfies @benadida's crazy paranoia, so it closes #35.  In other news, the 'forgot password' flow is now complete (this change solves the case where you forget your password for an email and reset it with precisely the same password --- because auth is salted, the registration_status call will delay 'complete' until you actually click through.  tl;dr; - closes #18

fix registration_status - now it's more sophisticated.  in case you're adding an email it needs you to be authenticated and checks that the same user owns both emails addresses.  in case you're verifying or re-verifying an email to creat an account it checks to see if the new credentials you provided work yet (transition only occurs when you click through the email link.  all tests passing again.

added email config to make testing email easier - be careful on production. Fixed sub-bug in db.js, callback not returned.

generate a persistent secret for cookie encryption at first server run.  still in pursuit of zero-config and as stateless as possible.

fix set_key wsapi on authority, now properly associates a NEW key with an EXISTING email address owned by the currently authenticated user

implement 'identity sync' which basically triggers client re-keying of identities that the server knows about but the client doesn't.  Also invalidates ids that the user has removed (probably on another device).  Also this is the proper place for revocation and key refresh to occur.  one transaction + one per key reset (though that could be consolidated)

implement polling in dialog and related wsapi in server, this is when waiting for email verification, subsequent to sign up