HAMMER 38A/Many: Undo/Synchronization and crash recovery

HAMMER 38A/Many: Undo/Synchronization and crash recovery

* Separate all frontend operations from all backend media synchronization.
  The frontend VNOPs make all changes in-memory and in the frontend
  buffer cache.  The backend buffer cache used to manage meta-data is
  not touched.

  - In-memory inode contains two copies of critical meta-data structures
  - In-memory record tree distinguishes between records undergoing
    synchronization and records not undergoing synchronization.
  - Frontend buffer cache buffers are tracked to determine which ones
    to synchronize and which ones not to.
  - Deletions are cached in-memory.  Any number of file truncations
    simply caches the lowest truncation offset and on-media records
    beyond that point are ignored.  Record deletions are cached as
    a negative entry in the in-memory record tree until the backend
    can execute the operation on the media.
  - Frontend operations continue to have full, direct read access to
    the media.

* Backend synchronization to the disk media is able to take place
  simultaniously with frontend operations on the same inodes.  This
  will need some tuning but it basically works.

* In-memory records are no longer removed from the B-Tree when deleted.
  They are marked for deletion and removed when the last reference goes
  away.

* An Inode whos last reference is being released is handed over to the
  backend flusher for its final disposition.

* There are some bad hacks and debugging tests in this commit.  In particular
  when the backend needs to do a truncation it special-cases any
  negative entries it finds in the in-memory record tree.  Also, if a
  rename operation hits a deadlock it currently breaks atomicy.

* The transaction API has been simplified.  The frontend no longer allocates
  transaction ids.  Instead the backend does a full flush with a single
  transaction id (since that is the granularity the crash recovery code will
  have anyway).