Introduce lightweight PMTU probe replies.

When replying to a PMTU probe, tinc sends a packet with the same length
as the PMTU probe itself, which is usually large (~1450 bytes). This is
not necessary: the other node wants to know the size of the PMTU probes
that have been received, but encoding this information as the actual
reply length is probably the most inefficient way to do it. It doubles
the bandwidth usage of the PMTU discovery process, and makes it more
reliable since large packets are more likely to be dropped.

This patch introduces a new PMTU probe reply type, encoded as type "2"
in the first byte of the packet, that indicates that the length of the
PMTU probe that is being replied to is encoded in the next two bytes of
the packet. Thus reply packets are only 3 bytes long.

(This also protects against very broken networks that drop very small
packets - yes, I've seen it happen on a subnet of a national ISP - in
such a case the PMTU probe replies will be dropped, and tinc won't
enable UDP communication, which is a good thing.)

Because legacy nodes won't understand type 2 probe replies, they are
only used with nodes that are using the experimental protocol.

Note that in theory this shouldn't break bandwidth estimation, though it
probably makes it somewhat less reliable since the estimation is now
based on the size of the probes being replied to instead of the replies
themselves, thus jitter will contribute twice to the results.
Improve bandwidth estimation for type 2 MTU probe replies.

This patch adds timestamp information to type 2 MTU probe replies. This
timestamp can then be used by the recipient to estimate bandwidth more
accurately, as it will only be affected by timing in one direction, not
during the complete round trip.