Since the protocol specifies the use of 16 bit counters, it's best to
reflect these in the API as well.

Turn arranging usize into u16

The expected index is a u16 at the protocol level, but the arranging
implementation for orderingstream does not take this into account. This
caused sending over 2**16 ordered packets to simply default to the
`None` case and get ignored. This patch solves that issue.

Previously we would only store packets with indices higher than the
expected index, this is obviously not going to give us good results when
we receive packets 0..100 while we are currently expecting index 65500.

What this patch does is that it stores all incoming packets with the
condition: expected < index < expected + u16::max/2

With wrapping add this becomes slightly more complex but the gist is the
same.

Fix ordering arranging handler for >65536 packets

The previous patches would erroneously skip the value 32767 and drop the
next packet (32768). This patch and test ensures that this doesn't
happen.

Sending over 65536 packets would previously just saturate the top_index
which caused it to not accept any more packets. This patch shortens the
sequence acceptance by half but always loops around the max u16 value.

This means that at top_index = 0, all sequenced packets 0-32768 are
accepted, while at top_index = 50000, all sequenced packets 50000-65535
and 0-17233 will be accepted.

Ensure that `self.remote_ack_sequence_num` is always increasing

crossjob for building and testing laminar

The connection is disconnected if we have N packets-in-flight
simultaneously. Under normal usage we expect packets to be acked
regularly so that our packets-in-flight size is relatively small.

* Most changes are in `VirtualConnection` struct to make `process_incoming` and `process_outgoing` results make iterable.
* Introduced a new `PacketInfo` type.
* Bugfix covered by a test, when `last_sent`, was not set when sending `Unreliable` packets.
* Removed a lot of warnings when running `cargo clippy --tests`.