Work around a TPACKET_V3 issue with a timeout of 0.

See https://github.com/the-tcpdump-group/libpcap/issues/335 for details.
Rename nonblocktest to capturetest.

We're going to add more capabilities, making it a more general test of
the packet capture data path.
Default to blocking mode, and add flags to set non-blocking mode and timeout.
Clean up some error messages.
Add -m for immediate mode.

Fix the usage message while we're at it.
Oops, have to set the timeout before pcap_activate().
And use the timeout.
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).