key update logging

[marten-seemann]

The spec is not clear on when to log key updates. I'm trying to debug a failure of the key update interop runner test case, and qlog just doesn't give me enough information what's going on. The main problem is that there's no key phase information available on the PacketHeader.

• During the handshake (all keys with trigger tls), it's most useful to log when a new key becomes available, as it allows you to see why packets might end up as undecryptable.
• Key updates for 1-RTT keys are more tricky: For a locally initiated key update, it's only clear how to log the send key. You do compute the receive key at the same point, but you don't use it until the client has acted upon the key update.

I think the following would be the easiest:

1. Add a key_phase field on the PacketHeader. This is the key phase N, not the key phase bit. The receiver will know the full key phase value after successfully decrypting a packet. For undecryptable packets, there should be a key_phase_bit field.
2. Split the key_updated event: The event in its current form makes a lot of sense for TLS-initiated updates. For 1-RTT key updates, there's no need to distinguish between the server_1rtt_secret and the client_1rtt_secret.

[rmarx]

Related to #52

[rmarx]

Fixed in #390.