Allow sending NEW_TOKEN frames before TLS NewSessionTickets

This issue was [originally opened in the quic-go repository](https://github.com/quic-go/quic-go/issues/4095).

Currently, it is not possible to make use of QUIC's address validation tokens if the server sends the NEW_TOKEN frame before sending the crypto frame containing the TLS NewSessionTicket. The address validation token gets stored, then thrown away.

It currently works as follows:
* Upon arrival of a NEW_TOKEN frame, the token [gets stored alongside its associated server ID](https://github.com/google/quiche/blob/39539964f9d5b173c01de08c0f13063f6b120a45/quiche/quic/core/crypto/quic_client_session_cache.cc#L119) (i.e. a combination of host and port) inside a cache that holds TLS sessions.
* When a new session ticket arrives, the session [gets added to the cache entry for the associated server](https://github.com/quic-go/quic-go/blob/4a046185b7d5275fd70504d2d630d10e731dbcc6/connection.go#L760)
* This new session does not specify the same QUIC transport parameters and is therefore assumed to be related to another, more recent session. The old cache entry (containing the token) [gets removed and a new entry without the token is inserted](https://github.com/google/quiche/blob/39539964f9d5b173c01de08c0f13063f6b120a45/quiche/quic/core/crypto/quic_client_session_cache.cc#L65).

Is the described behavior on purpose or is it a bug?
AFAIK, a client should be able to use tokens independent of the TLS session ticket.

If this is a bug, maybe it would make sense to copy an existing address validation token from the existing cache entry into the new cache entry for the same server ID before deleting the existing cache entry. Let me know if I should contribute this solution to the QUICHE project if the solution is fine.