vmhost/accumulator signal management

[zippy]

we now need refactor and build a better version of the signal sending/delivery/response system. This entails:

• enhancing SEND so you can have blocking, or non-blocking version depending on whether you need to wait for the RESPONSE or if you are ok just with knowing if it was accepted for delivery, or delivered or something less than a response. If you do need a response, we should also be able to add a callback run-tree to be executed when we get the response, or in that case should this be handled by planting listeners, or is that the same thing?
• fix receptor addressing in signals to take into account membrane crossing, etc (see #32)
• unify RESPOND signal handling with SEND signal handling. Currently RESPOND puts pending response signals on the end of the RUN_TREE and assumes something else will pick them up for handling... Nothing does... :-P

Currently RESPOND puts its response signal on the end of the run_tree it's executing under, and that run_tree is a sub_node of the signal that triggered the action. This is ok, but we don't have a signal ID mechanism from the sending end, so that responses can get matched up to correct initiating run-tree.

[zippy]

619dca7a0 adds asynchronous version of SEND. Currently you just add BOOLEAN child on as a parameter to SEND to make this happen.

[zippy]

a bunch of commits have no brought this to a pretty good place with responding now working distinctly from sending, etc, so I'll close this ticket and future enhancements will go in their own tickets.