kernel - Fix SMP races with vnode cluster fields

* The better concurrency we have due to the recent buffer cache work has
  revealed a SMP race in the vfs_cluster code.  Various fields used by
  cluster_write() can race and cause the wrong buffers to be clustered to
  the wrong disk offset, resulting in disk corruption.

* Rip the v_lastw, v_cstart, v_lasta, and v_clen fields out of struct vnode
  and replace with a global cluster state cache in vfs_cluster.c.

  The cache is implemented as a 512-entry hash table, 4-way set associative,
  and is more advanced than the original implementation in that it allows
  up to four different seek zones to be tracked on each vnode, instead of
  only one.  This should make buffered device I/O (used by filesystems)
  work better.

  Cache elements are heuristically locked with an atomic_swap_int().  If
  the code is unable to instantly acquire a lock on an element it will
  simply not cluster that particular I/O (instead of blocking).  Even though
  this is a global hash table, operations will have a tendancy to be
  localized to cache elements.

* Remove some manual clearing of fields in UFS's ffs_truncate() routine.
  It should have no material effect.
hammer2 - stabilization, improvements

* Improve hammer2_io hysteresis by keeping track of a simple activity
  metric when figuring out what to free.  Instead of cleaning out all
  free hammer2_io structures the code now tries to clean out only half
  of them when the hysteresis limit is reached.

* Remove some debug fields, add some debug fields.

* Refactor the memory load flush/wait code.  Instead of tracking the number
  of chain structures we track the number of MODIFIED chain structures,
  and stage early flushes and resource memory use waits based on that.

* Add temporary debug procedure hammer2_chain_assert_not_present() which
  asserts that a chain being created will not collide with a chain already
  present.

* Fix a bug related to freeing non-stale chains that could corrupt the
  flush algorithm.

* Fix bugs related to races between lookups and delete-duplicate operations.
  Races can occur because a delete-duplicate does not lock the chain->above
  core.

  This was a nasty one.  A delete-duplicate race can cause a lookup to
  find a DELETE+DUPLICATED chain, but just testing the DUPLICATED bit
  doesn't detect the race.  Instead we have to test whether the bit has
  changed between the spin-locked layer/RBTREE search and the locking of
  the chain that was found.

* Fix a bug in h2ignore_deleted().  When a chain is DUPLICATED, the
  delete_tid must be tested for any bref type.  Not testing this was
  allowing delete-duplicates on inodes to cause chains with the MOVED
  flag set to be left dangling in the in-memory topology and never
  get freed.

* Refactor the flush core a bit, in particular handle a case where
  we were improperly clearing the MOVED bit for a chain which had
  flush-deferred children.

* Remove some unused flags.

* Handle a hardlink shifted-upward race in hammer2_inode_lock_ex().