Zero-Lenght Connection ID Negotiation

The Quic RFC says:
> [7.2. ](https://datatracker.ietf.org/doc/html/rfc9000#section-7.2)[Negotiating Connection IDs](https://datatracker.ietf.org/doc/html/rfc9000#name-negotiating-connection-ids)
> When an Initial packet is sent by a client that has not previously received an Initial or Retry packet from the server, the client populates the Destination Connection ID field with an unpredictable value. This Destination Connection ID MUST be at least 8 bytes in length. Until a packet is received from the server, the client MUST use the same Destination Connection ID value on all packets in this connection.

Passing an `EmptyQuicConnectionId()` to the `QuicConnection` constructor currently causes Quiche to use a zero-length Destination Connection ID from the first packet being sent. This results in the connection being dropped by implementations that implement the above rule strictly, such as quic-go; quic-go ticket for reference: quic-go/quic-go#4465.

If complying to this is deemed the responsibility of the library user, it may be worth mentioning this in the `QuicConnection` constructor comments. If complying to this is considered the responsibility of the library itself, it may be worth automatically generating a random Destination Connection ID until one is received from the server (if none was provided by the library user).