This can (will ?) be done reading chars from the bot and testing received_chars == reset_chars. Problem is: what happens if the recevied chars are intepreted as reset chars, but shouldn't ? Maybe more than *one* reset char is required, so probability to get those in a "normal" communication is small...

Detects reset char (and also emergency char, ready for other special chars) at different steps:
  * while echoing: the bot resets before receiving all chars
  * in response: when a return value is expected, check what the bot gives
  * in a flush, using com_manager.flush(), not com_manager.communicator.flush(): analyse what's actually been flushed by the bot

Note raw_send/raw_receive in manager doesn't perform checking (keep the "raw" mode). Also note that there was a reset detection which was primarly done in the communicator (was also hardcoded...) so remove this logic and put it in the manager. As a consequence, every action done directly with the communicator won't be checked. That's normal.

Should this feature be implemented as special events ? Thus, using the event manager ? Actually, "reset" or "emergency" are just events. Special events as they're not linked to a specific action. Also, what if don't want to use an event manager ?

"reset" and "emergency" are not just events, as they can occur within all the communication process (echo,sof,eof,response,ack...) and not just the response (which is what can be considered as the basis of an event generation).

Crappy implementation... Need to really avoid the master/slave model. See ticket #23

See ticket #23