Extend event framework to support a standard serializable payload

[Qinusty]

As this is essentially opening up a new data type that can be put 'on the wire', (including the scope to have pubsub sinks in a similar fashion to the existing package publishers) does it make sense to have a defined expectation on what constitutes an 'event'?.

I think that the definition of an event can remain quite flexible, the exact reasoning behind a new event can be discussed during the implementation and review of specific event additions. As for how verbose this becomes, we can review this at a later date but the sinks can dispatch events in a filterable manner e.g. to specific type topics for a kafka sink (for example).

The event introduced here exercises all of the methods provided by the interface (component, type, message) when generating the logrus output. Could DispatchEvent() potentially pass a struct (validated with a schema for expected fields, format etc as with packages) constructed from the interface methods to the event handlers AddEvent() instead of the event itself?

Yeah I think this might need some tweaking to have an easily method of encoding data for transmission. We might want some form of standardised event payload which the individual Event implementations can populate. The current method of having the sink switch based on the event type isn't very extendable for many sinks and many events.

Originally posted by @Qinusty in #89 (comment)

[tom--pollard]

Just so it's not lost, logging this comment as an example of a usecase for transmitting additional/auxiliary data which could be supported by events supporting a payload that allows for extensibility.

#89 (comment)