Enforce stricter extensibility for ProtocolEventData

[rmarx]

Fixes #192.

Currently, $ProtocolEventData accepts just about anything, which makes it extensible but very useless for any real validation.

By not explicitly assigning the * text => any to the type in the main doc, we keep the extensibility, but improve validation capabilities.

This also properly adds the Generic and Simulation events to the $ProtocolEventData, which they really should have been from the start ;)

[LPardue]

I recall we had some previous discussion about this. I'd never acknowledged this trigger field (from a serializer or parser perspective). Are we aware of anyone using it?

[LPardue]

To clarify, up till now every instance of a $ProtocolEventData, such as parsing a H3 frame https://quicwg.org/qlog/draft-ietf-quic-qlog-h3-events.html#section-4.6, had an optional trigger field. This is not something I ever implemented for quiche. For serialization, that's no problem because the field can be omitted in logs. But for parsing, it is a problem, because I would not deal well with a qlog file that included such triggers.

That's my faul for omitting it from the quiche implementation in the first place. I support this change removing trigger, it means my implementation will be correct. However, anyone that is currently making use of trigger in event bodies may be surprised by this change. Hence the ask, is anyone using it?

If they are, it would be good to know if its inside a few events, or many. We can always add an explicit trigger to events where it makes sense. I don't think it makes sense for there to be a blanket trigger.

[rmarx]

Discussed during editors meeting:
@LPardue will send an email to the mailing list detailing this change and asking for feedback before merging.