Threads are a bad idea because for now the filter API is not guaranteed
to be state-less. The interface is now synchronous, which should be
enough for most filters.
The refactoring brought other changes, the most important being the
concept of modular input sources and output destination and the complete
rewrite of the procedural macro.
The main goal of events/reports is to update a context object, which
will be used in filters to generate a response. It is now possible to
use any object implementing both Clone and Default as a context object.
It is also possible to define no context at all.
Many filters requires to keep a state within a session. Although it not
currently possible to do so, the callback now accept a mutable object of
type NoContext. This is the first step, the next one will be to accept
any type that implements both Clone and Default.
An other step will be to allow the user to define different callback
parameters depending on his/her needs.
The construction of an EventHandler object should not be directly done
by the client. Instead, it is easier to use procedural macro to
automatize the process, hence exposing a nice and simple interface. Such
use of procedural macros requires to crate an additional crate.
