Add new Bluetooth link-layer header types.
Add support for Bluetooth Linux Monitor interface

Interface "bluetooth_monitor" is used to monitoring all Bluetooth
adapters together on Linux platform.
Merge pull request #342 from MichalLabedzki/master

Add support for Bluetooth Linux Monitor interface
Check for HCI_CHANNEL_MONITOR for Linux Bluetooth Monitor support.

Support the Linux Bluetooth Monitor mechanism if:

	we support Linux Bluetooth;

	struct sockaddr_hci includes an hci_channel field;

	HCI_CHANNEL_MONITOR is defined by the Bluetooth headers;

as there are some 3.x kernel versions in which struct sockaddr_hci
includes an hci_channel field but in which HCI_CHANNEL_MONITOR is not
defined.
Add a link-layer header type for the PROFIBUS data link layer.
Do userland filtering if we can't do kernel filtering.

If, for example, the filtering doesn't pass the kernel's filter
validator because it does backward branching, as would be the case if
"ip protochain" or "ip6 protochain" were used, we don't want to fail, we
want to fall back on filtering in userland.

Use some PCAP_ERROR_ values while we're at it, to match what pcap-bpf.c
does.
Work around annoying Android problem.

For various annoying reasons having to do with DHCP software, some
versions of Android give the mobile-phone-network interface an ARPHRD_
value of ARPHRD_ETHER, even though the packet supplied by that interface
have no link-layer header, and begin with an IP header, so that the
ARPHRD_ value should be ARPHRD_NONE.

Detect those devices by checking the device name, and use DLT_RAW for them.
Pick up fix from Android libpcap.

(Did anybody ever send this fix upstream to us?)
Add support for Apple's DLT_PKTAP.
Add more details to a comment.
fix compiling on Windows after commit dbdee51
.travis.yml: install libusb-1.0-0-dev and libdbus-1-dev devel libs
.travis.yml: set silent operation for make
Make the code to set the type a bit clearer.

Make it

	if (case 1)
		type = type 1;
	else if (case 2)
		type = type 2;

and indent it a bit more clearly.
Fix some socket file descriptor leaks.

Thanks to Coverity for finding the first one.  The second one wasn't as
obviously a leak, so Coverity didn't find it; don't save the socket FD
in the pcap_t structure until we've succeeded in activating the pcap_t,
so that leaks such as that will be more obvious to Coverity.
Use strlcpy() uniformly.

That ensures null-termination of strings; Coverity complained about
that.

That also obviates the need to manually null-terminate strings, so get
rid of some now-unnecessary null-termination.
And another strlcpy().

This one replaces a strcpy(); that one was also found by Coverity.

(I suppose we should check whether strlcpy() prematurely null-terminates
the string, and report a "no such device" error - or, in the create
routine, check to make sure the device name fits within all of the
relevant ioctl data structures and, if not, return a "device doesn't
exist" error.)
Make sure the device name we're handed will fit into an ioctl.

If not, the device presumably doesn't exist, as the Linux kernel
shouldn't support creating such a device; make sure we don't just use a
truncated version of the name in ioctls.
Supply an error message for "out of memory" in the create routine.
Fix the case where the requested resolution is higher than the iface resol.

(I'd say "interface resolution", but, well, this is Git, home of the
"fit a summary of the change in one line, even if it kills you", and I
happen to have microEMACS's running in an 80-position-wide window.  Even
that's probably too long for Git....)

This should fix issue #349.