Signal-based hooks

[AlexandreDecan]

(Discussion introduced in #72)

Another thing that I would like to change is the way we defined hooks and "notifications". Basically, in the current implementation, we have many direct hooks (like the many methods of PythonEvaluator that are called by the interpreter at specific points), "indirect hooks" (like the meta-events to support property statecharts) and "observable objects" (like the clock, the event queue, the trace, etc.). I would like to have a more uniform approach to deal with all these "hooks", and I'm currently looking into a signal-based communication between components (e.g. the interpreter defines signals like before execute, before step, after execute*, on state entered, on consumed event, etc., and other components can subscribe to those signals and attach callbacks to them). This will greatly simplify many parts of the current implementation, but will also contain a lot of breaking changes, e.g.:

• Property statecharts could be implemented as a subclass of Interpreter, with an additional method listen(other_interpreter) that subscribes and reacts to these signals. As such, an observed interpreter won't know it's currently observed (which is something one can expect. In the current implement, the observed interpreter "attaches" property statecharts);
• Bound callables could subscribe to the event sent signal. Similarly, the binding process will be inverted: a statechart will "listen" to another statechart, instead of binding a "listening statechart" to the current interpreter;
• Clock could generates a time changed signal so that a ClockBasedRunner could listen to a clock and executes the statechart accordingly.
• A debugger will simply listen to (nearly all) signals;
• Event-based runner could subscribe to the event queued signal to jump to the next event;
• An code evaluator won't have to implement such a complex interface (execute_on_entry and execute_on_exit were introduced only because we needed to be notified when a state is entered or exited); ...

Given the breaking nature of these changes, I'll reserve them for Sismic 2.0.0

[AlexandreDecan]

We will probably implement a more general hooking-system.