nmhive.py: Use notmuch behind GET /tags

I stick with the NMBPREFIX environment variable for consistency with
nmbug itself.  I also drop 'app.debug = True', to avoid trouble like:

  $ ./nmhive.py
   * Running on http://0.0.0.0:5000/
   * Restarting with reloader
  A Xapian exception occurred opening database: Unable to get write
    lock on /.../xapian: already locked
  Traceback (most recent call last):
    File "./nmhive.py", line 83, in <module>
      mode=notmuch.Database.MODE.READ_WRITE)
    File "/.../notmuch/database.py", line 154, in __init__
      self.open(path, mode)
    File "/.../notmuch/database.py", line 214, in open
      raise NotmuchError(status)
  notmuch.errors.XapianError

because with 'debug = True', Flask tries to run two instances of this
process simultaneously, but only one can hold the write lock at a
time.  If we want to scale this up to multiple writing
threads/processes, we'll probably want to make the persistant Database
instance read-only, and either acquire a write lock as necessary, or
just instantiate a read/write database for each PUT.  For now, it's
easy enough to just have a single thread.
nmhive.py: Use per-request database connections.

On #notmuch, Austin Clements just said:

  Opening the database always gives you a consistent snapshot, so you
  won't see changes unless you close and reopen it.  However, opening
  in read-only mode is quite cheap.

so I'm going to drop my global connection in favor of per-request
connections.  This also allows me to cleanup after aborted atomic
transactions (when I implement the POST backend), because notmuch does
not currently expose Xapian::WritableDatabase::cancel_transaction.  It
also allows other readers to see the new data, since notmuch only
commits changes when the database connection is closed.  Finally,
David Bremner pointed out that holding the read/write lock for an
extended period of time is just bad form.
nmhive.py: Use notmuch behind GET/POST /mid/<message_id>

With more per-request connections.  I don't currently check for
read/write lock contention, but ideally we'd return '202 Accepted' in
those cases and queue the changes for the next successful read/write
connection.