Event listeners (and filtering) for state events

[Half-Shot]

Following conversation on #43:

Happy with #44 for keeping old functionality.

Now, onto the other issues:

there are so many different ways to divide the events up into groups that one may want to listen to. For example, currently per-room and per-client listeners are supported (modulo this bug report); the docstring ("Incoming event callbacks") seems to also indicate per-user listeners.

Regrettably, we do not have per user listeners. Users are 'fun' because we can either have profile wide changes or room wide changes to them (via m.room.member events which usually but not always are global changes, so context is everything!) .

I find that behaviour pretty simple and intuitive, but we could be more granular adding arguments to the two add_listener functions (like event_type='m.room.message' or event_family='state')

I like this. It might be the best way to do it because I think specific functions for each type is ridiculous. Potentially you might want to add a few wrappers for things like topic, but I'm not fussed. Event family is probably overkill, add_state_listener and add_listener would be quite fine. I also would add an option for exclusivity if people want it.

You'd end up with something like:
add_state_listener(func, event_type=None, exclusive=False)