v0.4.1

UDP GSO now batches, which it never did.

GSO puts several datagrams in one sendmsg and the kernel splits the buffer into
equal segments, only the last allowed to be shorter. shb built datagrams back
to back and declined to batch any that came out a different size. That sounded
right and meant it never batched at all: one datagram is 1188 bytes and the
next 1190, because a packet number or a stream offset crossing a varint width
moves the total by a byte or two. Every send carried one segment, and the
machinery around it - the pinned msghdr, the control message, the probe at
start-up - was being carried for nothing.

Datagrams after the first are now built to the size of the first, which the
packet builder takes as a limit rather than as something to pad up to
afterwards. Padding afterwards cannot work: once the frames have overshot, the
packet is already encrypted. Batching begins only when the first datagram came
out nearly full, because a short one means there was nothing more to send.

With a 266 KB request body that is 28 to 64 segments per send against one
before, and 20.9 MB/s leaving the machine against 0.65. Requests per second do
not move against a server that answers before reading the body; the win is in
what goes out. Small requests still send one segment, which is correct, and
measure unchanged.

Also drops the bytes crate from the dependency list - it was there for
quinn-proto's datagram type and nothing has used it since 0.4.0 replaced the
transport - and removes what the QUIC rewrite left behind: predicates nothing
asks for, connection IDs the packet decoder was copying out of every 1-RTT
packet for no reader, and a stream lookup written out five times.