feat: disable Initial ACK if server sends coalesced Initial+Handshake #1

As discussed in quic-go#4007, uQUIC would prefer having this OPTIONAL feature implemented since observation indicates it is implementation-specific:

Mozilla Firefox and Google Chrome will send Initial ACK only if server sends an Initial ServerHello that is NOT coalesced with a Handshake packet. Otherwise, as the Initial ServerHello being coalesced with Handshake EncryptedExtensions, they will omit the ACK to the Initial ServerHello.

Apple Safari behaves differently, it will explicitly ACK to the Initial ServerHello even when it is coalesced.

Related RFC9001 section:

4.9.1. Discarding Initial Keys
Packets protected with Initial secrets (Section 5.2) are not authenticated, meaning that an attacker could spoof packets with the intent to disrupt a connection. To limit these attacks, Initial packet protection keys are discarded more aggressively than other keys.

The successful use of Handshake packets indicates that no more Initial packets need to be exchanged, as these keys can only be produced after receiving all CRYPTO frames from Initial packets. Thus, a client MUST discard Initial keys when it first sends a Handshake packet and a server MUST discard Initial keys when it first successfully processes a Handshake packet. Endpoints MUST NOT send Initial packets after this point.

This results in abandoning loss recovery state for the Initial encryption level and ignoring any outstanding Initial packets.