Support dumping dependency tree in dot format about ureact

[YarikTH]

Better idea: introduce node visiting feature. Pass visitor like functor to receive full info about used nodes. Like

struct F
{
  void operator()( node_info::id );
  void operator()( node_info::depth );
  void operator()( node_info::label );
  void operator()( node_info::children );
  void operator()( node_info::value<T> );
  void operator()( node_info::type<T> );
  // maybe node_type? signal/event/observer
};

context ctx;
ctx.peek_node_info( F() );

So user can use such info for whatever reason and convert it into needed format.

To achieve this context should have pointers to at least 0 depth nodes so we can iterate them. Also we need interface to add custom labels to nodes. This feature should be disableable using define, because it adds runtime overhead to store node pointers in context and to store label strings in nodes.

[YarikTH]

Maybe reimplementing of logging interface is fine too.

[YarikTH]

I think that it is easier to make it all via IListener interface that can be passed on the context creation. This interface will be analog of cpp.react's EventLog and IReactiveEngine. If user receive events about all the internal actions, then he can not only regenerate node graph on his side, but also see all the process, visualize it in any way he wants.

Here is combination of cpp.react's interfaces with descriptions:

struct IReactiveEngine
{
    // Hard to understand that it means exactly.
    // It is range between turn creation and actual change propagation
    void OnTurnAdmissionStart(Turn& turn)  {}
        // No event
    void OnTurnAdmissionEnd(Turn& turn)    {}
        // No event

    // Change propagation
    void Propagate(Turn& turn)  {}
        // No event

    // Node creation/destruction
    void OnNodeCreate(NodeT& node)  {}
        class NodeCreateEvent
    void OnNodeDestroy(NodeT& node) {}
        class NodeDestroyEvent

    // Static attach/detach on creation/destruction
    void OnNodeAttach(NodeT& node, NodeT& parent)   {}
        class NodeAttachEvent
    void OnNodeDetach(NodeT& node, NodeT& parent)   {}
        class NodeDetachEvent

    // Dynamic attach/detach in the process of change propagation. Needs extra actions, but basically the same
    void OnDynamicNodeAttach(NodeT& node, NodeT& parent, Turn& turn)    {}
        class DynamicNodeAttachEvent
    void OnDynamicNodeDetach(NodeT& node, NodeT& parent, Turn& turn)    {}
        class DynamicNodeDetachEvent

    // Pulse means that IReactiveNode::Tick() did something, so children should be updated.
    // IdlePulse means that IReactiveNode::Tick() did nothing
    void OnNodePulse(NodeT& node, Turn& turn)      {}
        class NodePulseEvent
    void OnNodeIdlePulse(NodeT& node, Turn& turn)  {}
        class NodeIdlePulseEvent

    // Called inside IInputNode::ApplyInput(void* turnPtr) to notify that input node is triggered
    // Basically the same as OnNodePulse, but for input nodes
    void OnInputChange(NodeT& node, Turn& turn)    {}
        class InputNodeAdmissionEvent

    // Events inside IReactiveNode::Tick(void* turn) that show where actual calculation is performed
        class NodeEvaluateBeginEvent
        class NodeEvaluateEndEvent

    // Not used in legacy1 cpp.react
        class TransactionBeginEvent
        class TransactionEndEvent
        class UserBreakpointEvent
};

Ureact has derived from cpp.react and evolved a little, so interface would differ. So, it is better to start from the easiest cases like nodes construction/destruction and their connections and continue form this.

Such logging facility is not free performance wise, so it should be optional and lay under some define that can disable it when it is not needed.

Unlike EventLog that has timestamps and tons of separate event classes with own serialization, I see ureact log interface as a IReactiveEngine's analog with tons of virtual methods which user should overload to be notified. So user can get the timestamp, and other info he likes.

Also, seeing tree of anonimous nodes which types, values etc we can't see it is not so informative, so need to come up with some idea how to add such info and pass it in the interface.

[YarikTH]

Also, it's good idea to make #125 first. Because otherwise logging interface will be in details namespace, because it uses classes and enumerations from this namespace.