Use cases for the TRIGGER field

[rmarx]

To have the TRIGGER as a top-level field, there need to be good use-cases and people willing to use this in their tools.

Since the TRIGGER will only be useful for specific events (e.g., PACKET_RETRANSMIT can be due to several loss-detection related situations) and it's value might in some cases also just be deduced from the context of surrounding log messages, it is debatable it will have much use in practice.

An alternate approach could be to log it as part of the DATA field of specific events, instead of as a top-level field.

[rmarx]

Feedback from among others @nibanks indicates that adding the TRIGGER as an optional member of the DATA is probably the better option down the road.

We could think about extending that: any event_field could conceptually be added to data. This would be useful for other event_fields as well, that are not the same for all events (which would be in common_fields) but also don't need to be logged for each event (event_fields). Maybe something like dynamic_fields? and then you do data.dynamic to fetch them? (e.g., data.dynamic.trigger). This is nice an flexible, but a potential nightmare to support properly in tooling...

[rmarx]

Fixed in #23. Triggers are now properties of the data field with hints in the draft as to their values in separate contexts.

Decided not to do the "dynamic_fields" approach for now to keep complexity manageable.