Work around a TPACKET_V3 issue with a timeout of 0.

See https://github.com/the-tcpdump-group/libpcap/issues/335 for details.
We can't use TPACKET_V3 in immediate mode, so fall back on TPACKET_V2.
Discourage the use of a zero timeout.

On BSD, OS X, and possibly Solaris 11 and later, it could cause your
application to wait indefinitely long for packets, which you probably
don't want.

On Linux, it could do any of a number of things, none of which will do
very much buffering of packets; if that's what you want, use a very
small timeout value (or use immediate mode).  Making it block forever is
difficult if not impossible.

On Solaris 10 or before, it's not clear from the bufmod(7m)
documentation what it would do; it could be made to wait indefinitely
long, or return packets immediately, or return after an
arbitrarily-chosen timeout, if we wanted to make it do so.

I'm too lazy to check what it'd do on various other OSes (other than the
ones that have no notion of a read timeout).
Fix pcap_loop() with a count of 0 and TPACKET_V3.

A count of -1 *or* 0 should mean "loop forever", so only a count > 0
means to use the count to limit the number of packets to process.
tweak manpages formatting

Most manpages markup NULL and PCAP_ macros with .B, fix a few remaining
files for consistency.
Fix builds on systems without TPACKET_V3.
Use HAVE_TPACKET3 rather than TPACKET_V3 to test for TPACKET_V3 support.

That's what's done in other places in the file.
Add a PACKET_COUNT_IS_UNLIMITED() to test for a packet count <= 0.

In read routines, a packet count <= 0 means "keep supplying packets
until you run out of packets in the buffer", and it means "keep supply
packets until the loop is broken out of or you get an error" in
pcap_loop().

Use the macro in all tests for that, so the right test is always done
(i.e., a count of 0 means "unlimited", not "supply zero packets"); this
fixes some cases where we weren't doing the right test (and hopefully
encourages programmers to use it and get the test right in new modules).