HAMMER VFS - Add code to reduce frontend vs flusher locking conflicts

HAMMER VFS - Add code to reduce frontend vs flusher locking conflicts

* Implement a Pulse-width modulated time-domain multiplexer on B-Tree
  cursor operations which splits fronttend operations from backend flusher
  operations.

  The larger the number of inodes undergoing reclamation, the greater the
  pulse width given over to locking operations initiated by the flusher.
  Frontend operations (typically reads) are given smaller and smaller
  slot widths as the flusher gets more overloaded.

  The advantage of this mechanism is that we are not simply imposing a
  delay in the reader, we are imposing a variable-length time slot during
  which the reader is able to grab a B-Tree cursor.  This allows linear
  and partially cached operations to 'burst' many operations within the
  slot, allowing them run at nearly full speed and not imposing an artificial
  performance limitation for linear I/O.

* This solves a major deadlock stalling issue that prevented the flusher
  from being able to actually flush sufficient I/O to keep up with the
  inode backlog that e.g. blogbench creates, causing excessive locking
  stalls throughout the HAMMER filesystem, particularly when many file
  inodes are being cycled through.

* When running blogbench --iterations=150 prior to this change write
  performance would drop to unacceptable levels and read operations
  (particularly things which cycle through inodes like 'find' and 'ls')
  would stall for unacceptably long periods of time, often resulting
  in diagnostic cache_lock messages on the console showing namecache
  blockages in excess of 100 seconds.

  With the change namecache blockages are significantly reduced in both
  frequency and duration, find and ls operations are able to run
  concurrently with a heavy multi-file write load, and blogbench shows
  improved write performance while still giving a reasonable priority to
  read operations (which is what we want).

* Rename a few of the sysctls to normalize internal vs external variable
  names.