Add a "modifiers" hook to allow extension authors to mutate/redact event data

[Zsailer]

Addresses #11

• Modifiers are added before the event is validated and emitted. That means, the mutated event are still required to follow the event schema.
• Modifiers are applied to all incoming events. Authors of modifiers can special case events inside their functions. This is slightly different than the listeners API in Add Listeners API #10, which attaches listeners to specific events.
• This enforces a strict function/method signature (types included) for all modifiers added to the eventlogger.

[Zsailer]

This is ready for final review and should likely be merged before #10.

[blink1073]

LGTM!

[Zsailer]

Thanks @blink1073!

I just added a new commit: 3c5689d. Do you mind taking another look? 😃

After working with this API more and thinking about previous chats we've had, I think making all of the public method/function APIs take dataclasses as arguments is a better approach. This gives us, the jupyter_events developers, more flexibility to change these APIs without causing backwards incompatibility.

[blink1073]

I don't think we need a separate class for ModifierData, it makes sense to me to return a new Event if you wish to modify any fields.

[Zsailer]

My reasoning for separating these dataclasses was thinking ahead about possible changes to the emit(...) method signature or the modifier signature, modifier(...), in the future.

Today, Event and ModifierData look equivalent, so .emit(data: Event) and def my_modifier(data: Event) could work. But what if we wanted to add arguments to my_modifier that don't belong in the `.emit(...) method? I was thinking we might want to decouple these input types so that these APIs could evolve independently from each other.

That said, I agree it would be much nicer to just have the Event dataclass. We could make any new attributes in the Event object optional in the future to allow for backwards compability.

[Zsailer]

Ok, I've consolidated these dataclasses 👍. It makes the API really nice and clean. Thanks @blink1073!

[blink1073]

LGTM!

[yuvipanda]

Hacking with @Zsailer in person!!! More comments left in person :D

[blink1073]

Should this list be private? I think it makes sense for it to be private and to have a remove_modifier function.

[Zsailer]

👍 Great idea. Fixed!

[blink1073]

LGTM!