Handle DLT_NULL correctly - the AF_ value is in host byte order, which

Handle DLT_NULL correctly - the AF_ value is in host byte order, which
may not be *our* byte order if we're reading a capture file from another
machine; we currently handle that by checking whether it looks like an
integer < 65536 or not and, if it's not, byte-swap it.

This also lets us handle OpenBSD DLT_LOOP as well - it's like DLT_NULL
except that the AF_ value is in *network* byte order.

(Old-style Linux loopback captures were also DLT_NULL, but the header
had an Ethernet type in it; there have also been captures where the
header was a PPP header.  For now, we just continue to assume that all
DLT_NULL packets are IP, and check the IP version field to decide
whether it's IPv4, IPv6, or something else.

We may want to consider adopting Ethereal's heuristics, which would at
least mean we wouldn't be reporting bogus packet types for old-style
Linux loopback captures and those weird PPP - ISDN4BSD? - captures,
although the version of libpcap that goes with this version of tcpdump
doesn't produce bogus DLT_NULL captures for Linux loopback devices.)