hammer2 - Retool dmsg mechanics to improve virtual circuit design 1/2

hammer2 - Retool dmsg mechanics to improve virtual circuit design 1/2

* Rip-out the circuit structures and forging code.  These changes simplify
  the DMSG code considerably.

* Retool the core command/response messaging mechanics to allow either
  side of a transaction to initiate commands and receive responses.

  This means we cannot use DMSGF_REPLY to determine whether the transmit-side
  or receive-side state RBTREE holds the msgid.  Instead we add two more
  flags DMSGF_REVTRANS and DMSGF_REVCIRC to tell the receiver which RBTREE
  holds the msgid and/or circuit id.

* Retool to allow transaction stacking.  Sub-transactions can now run under
  their parents.

* Retool the transaction code to provide virtual circuit functionality
  through the use of transaction stacking.

  With these changes, the normal SPAN mechanism which operates using
  open transactions can also be used to route messages over the SPAN.
  There is no longer a need to forge a return path because sub-transaction
  commands can now be initiated 'out' over an active, received SPAN
  transaction.

  This part is not completely working yet, it needs the actual routing
  code and some adjustments to the SPAN mechanism to prevent path ripups
  from interfering with any in-progress transactions.  Ultimately the
  availability of a new path would have two be detected by the end points
  so new 'connections' can be forged over the new, better path.