hammer2 - multi-thread read-ahead XOPs

hammer2 - multi-thread read-ahead XOPs

* Distribute asynchronous logical buffer read-ahead XOPs to multiple
  worker threads.  XOPs related to a particular inode are usually sent
  to just one worker thread to reduce collision retries.

  This works around the high messaging overhead(s) associated with the
  current XOP architecture by spreading the pain around.  And even though
  the default check code is now xxhash, distributing the checks also helps
  a great deal.  The H2 chain topology actually parallelizes quite well for
  read operations.

  Streaming reads through the filesystem now run at over 1 GByte/sec (they
  capped out at ~340MB/sec before).  The effect on things like 'tar'
  are not quite as pronounced but small-file scan/read performance will
  typically improve by a tiny bit too.

* This change is probably more SSD-friendly than HDD-friendly for streaming
  reads due to out-of-order queueing of the I/O requests.  I ran a quick
  read test on a WD black and it appeared to perform acceptably so for
  now I'm going to run with it.  Adjusting read-ahead scale via
  vfs.hammer2.cluster_enable can be used to find a good value (for now).

* Remove the 'get race' kprintfs.  This case now occurs very often due
  to distributed read-aheads.

* chain->flags must use atomic ops, fix some cases I muffed up in recent
  commits.