Measure latency on connections that were already established

[git-hulk]

The server side of a connection was only ever learned from a captured
SYN, so a connection that existed before tcpkit started was invisible:
packet_direction returned -1 for every one of its packets and they were
dropped without being counted. That is the normal case for the tool's
own documented use, since redis and memcached clients hold pooled
connections open for the life of the process -- tcpkit -i eth0 tcp port 6379 -p redis against a busy server could sit there printing
nothing at all until a client happened to reconnect.

When neither end of a data-carrying packet is a known endpoint, take
the lower of the two ports to be the service: clients draw from the
ephemeral range above it. Unlike guessing from the direction of the
first packet, that holds whether a request or a response is seen first,
which matters because a capture starts mid-conversation. A captured
handshake still wins, and the guess is only made once per endpoint.

Replaying a capture with no handshake, whose first frame is a response
to a request that was never captured, went from no output to correctly
reporting the following request against 10.0.0.2:6379.

🤖 Generated with Claude Code

[git-hulk]

Dropping this one without merging, at the author's request.

It added the fallback that guesses which side of a connection is the server when no TCP handshake was captured, so that latency is still reported for connections that were already established when tcpkit started.

PR #39 was stacked on top of this and has been rebased onto master, so it no longer carries this commit and can be reviewed on its own. Nothing merged to master depends on this change.

The design-established-connections branch is left in place, so this is straightforward to revisit if the approach is wanted later.