fix(toolkit): a TCP flow inside an IP-in-IP tunnel is keyed by the tunnel's outer addresses #1581

A TCP flow carried inside an IP-in-IP tunnel is keyed by the tunnel's outer addresses, not by the endpoints in the IP header that actually carries the TCP segment. Every connection through one tunnel that shares a port pair therefore merges into one flow, and the reported endpoints are the tunnel's, not the hosts'.

Repro on main (cc084357f). A 4in4 capture: Ethernet, then outer IPv4 192.0.2.1 → 198.51.100.2 (protocol 4), then inner IPv4 10.0.0.1 → 10.0.0.2, then TCP 40000 → 9 (SYN, data, FIN).

• TCP reassembly keys the flow as (192.0.2.1, 40000) → (198.51.100.2, 9) on the default and scapy engines.
• dpkt produces no TCP flow at all.

The #1575 worker measured 6in4, 6in6 and 4in6 too. The default engine uses the outer addresses for all four. scapy uses the inner ones for 4in6 only. dpkt drops all four. pypcapfile now warns once per capture, after #1575.

Expected: every engine keys the flow by the innermost IP header, the one whose payload is the TCP segment, as Wireshark's TCP conversations do. The trace endpoints should follow, so that all four engines agree.

Blocked until #1575 and #1579 merge, because the fix touches toolkit/pypcapfile.py and toolkit/pcap.py respectively, as well as the dpkt and scapy toolkits.