Fix trace_event errors with pcapint: and filters

If a packet arrives between the time a live pcap capture
is created and the time the filter is set, the pcap fd acts
as though there is a packet available even if pcap_next_ex will
time out due to no packets matching the filter.

This can wreak havoc with trace_event, which relies on select
to know whether it will be able to call trace_read_packet
without blocking. If the filter doesn't match any packets,
trace_read_packet will block forever -- defeat the purpose of
using trace_event in the first place.

The solution is to always try to consume a packet immediately after
calling pcap_setfilter. Any "bad" packets will be removed from the
queue until a packet that matches the filter is hit or pcap_next_ex
times out. Either way, select should work properly again, at the
cost of possible one legit packet being consumed during startup.

Thanks to Mike Schiffman for reporting this bug (and the previous
one re: inconsistent behaviour when the filter is bogus).