pcap-dbus code from Jakub Zawadzki
Merge remote-tracking branch 'github/master'
Pick up some fixes from a comment for the SourceForge bug for D-Bus support.

Fix the help message for --enable-dbus to say --enable-dbus, not
--enable-can, and call pcap_cleanup_live_common() rather than the
nonexistent pcap_live_cleanup_common().

Also, say "D-Bus capture" in the help message, to spell it correctly and
to clarify that we're only adding support for capturing on D-Bus (not
adding support for libpcap using D-Bus for some purpose or another).
Merge branch 'master' of git+ssh://bpf.tcpdump.org/tcpdump/master/git/libpcap
Fix D-Bus checks.

Check whether dbus-1 is installed before trying to get flags for it.
That way, if you don't have dbus-1 installed, you don't get pkg-config
errors printed.

Don't expect the shell to be able to run a command inside $() and have
the result expand to the standard output of that command; that's not a
feature present in all Bourne-compatible shells.  Use backquotes
instead.

If the user specified --enable-dbus, and dbus-1 wasn't found, fail -
they asked for D-Bus sniffing support, but we can't give it to them, so
let them know that they can't have what they want.  They either need to
install the package or stop specifying --enable-dbus.
If --enable-dbus isn't given, don't fail if dbus-1 isn't installed.

If --enable-dbus isn't given, we want to support D-Bus sniffing iff
dbus-1 is installed.  If it is given, we want to fail if dbus-1 isn't
installed, as the user explicitly demanded it.
Add a pcap-dbus.h header and include it in pcap-dbus.c and pcap.c.

That way, we ensure that the same function prototypes are seen when
dbus_create() and dbus_findalldevs() are defined and when they're used.

Also, add pcap-dbus.c to the list of "extra" files in Makefile.in, so it
goes into the release tarball.
pcap-int.h must be included before pcap-dbus.h, to get pcap_t etc. defined.
It's pcap-snf.h, not snf.h, and must be included after pcap-int.h.
Include pcap-canusb-linux.h to declare the exported functions.
Use 18 for DLT_IP_OVER_FC, explain the hell of ARPHRD_FC*.

18 is what RFC 4338 specifies as the ARP hardware type for RFC
4338-style IP-over-Fibre Channel; assume that if Linux ever implements
that it'll use 18 as the ARPHRD_ value for those interfaces, and also
encourage its use as the ARPHRD_ value for the interface even for RFC
2625-style IP-over-Fibre-Channel (perhaps providing some mechanism other
than looking at the ARPHRD_ value for code to find out what type of
IP-over-FC is being used, if necessary), and map it to DLT_IP_OVER_FC.

For the ARPHRD_FC* values (how do they correspond to ARPHRD_ values
anyway?), map them to a choice of link-layer header types, with the
default being DLT_FC_2, to *dis*courage their use in the future for
IP-over-FC and to allow capturing on Chistian Svensson's hardware
without a -y flag if frame delimiters aren't being included.