Keep track of lost packets as reported by pcap_stats

On my machine, if I generate the following IPv6 flood:

ip -6 neigh add fe80::1234  dev eth0 lladdr 00:11:22:33:44:55
nc -6 -u fe80::1234%eth0 1234 < /dev/zero

The traffic reported by iftop is much less than the reality, as iftop
can't read packets off pcap fast enough. This patch only demonstrate
the problem, I haven't started to dig into the cause yet.

Drop packets shorter than sizeof (struct iphdr)

When packets that are too short to be valid IP packets happen to start
with 0x45 or 0x60, iftop will still try to read source and destination
addresses, which will usually just be random garbage.

Note the assumption about what libpcap guarantees in the comments to
handle_ip_packet():

    * It is assumed that the snaplen (currently hard-coded to 1000) is
    * big enough to always capture the IP header past the L2 encap, and
    * that pcap never truncates the packet to less than snaplen; in
    * other words, that pcaphdr->caplen = MIN(pcaphdr->len, snaplen).

Do traffic accounting in pps

Add a "-u unit" CLI option, as well as a "bandwidth-unit" configuration file
option. With "-u packets", traffic is accounted using packets per second; the
other options are "-u bits" and "-u bytes".

"-B" is still recognized as synonym to "-u bytes".

The default is "-u bits", keeping the current behaviour of iftop (everything
is in bits/s, except the cumulative totals).

Silence a warning

Import iftop-1.0pre4

Import de iftop-1.0pre1