Converted ColorizingLogHandler into ConcurrentColorizingLogHandler

The new version requires no locking on the 'client' side (the code calling logger.<...>(msg)) and
relies on a separate thread for actual output. This helps with our 'Signaling' threads that can trigger
exceptions at any time.
[events] 'on(...)' is now one shot, add 'every(...)' for multi-shot events
Cosmetic
Fixed several non-trivial threading-related issues

The main issue was: subactions are not systematically cancelled when the
parent action is cancelled.  Correct implementation of this behaviour is
non-trivial due to hard-to-control locking issues that may arise when
ActionCancelled is raised.

Typical scenario:

'goto' starts 'move' and wait for move to be done via:

>>> while not move.done():
       pass

'goto' is going to spend most of its time acquiring the lock in
'done()', and when ActionCancelled is raised, it is highly probable that
the lock will be acquired and can not be released (if the lock is acquired
via a context manager, ie, a 'with' statement, this happen if the
exception is raised while the thread is inside the __enter__ or __exit__
methods).

To resolve the issue, we postpone the cancelation (ie, raising
ActionCancelled) until we are *outside of the threading module* (cf
line 75 of robot_actions.py).

This commit also fix potential issues in the Executor (that needs to be
thread safe).