Add new tunable 'net.link.ifqmaxlen' to set default send interface
  queue length. The default value for this parameter is 50, which is
  quite low for many of today's uses and the only way to modify this
  parameter right now is to edit if_var.h file. Also add read-only
  sysctl with the same name, so that it's possible to retrieve the
  current value.

r214236 & r214160:
The firmware does pad notifications to an even number of bytes (at least
the association notification), the included information though always
contains an elem block with an odd number of bytes. We handle the last
byte as if it might contain a whole elem block, this of course is not
true as one byte is not enough to hold a block, we therefore discard the
complete frame. The solution here is to subtract one from the actual
notification length, this is also what the Linux driver does. With this
change the frame ends exactly where the last elem block ends.

r214262:
The firmware always sets bit 14 and 15, to get the real associd we need
to clear those bits.

Fix monitor mode which is implemented by doing a firmware scan. This
is a port from stable/6, seems like the code got lost during the
background scan changes in r170530.

this opmode is not supported.

Approved by:	re (kib)

o correct rssi taken from rx descriptor; need dbm

o replace DLT_IEEE802_11 support in net80211 with DLT_IEEE802_11_RADIO
  and remove explicit bpf support from wireless drivers; drivers now
  use ieee80211_radiotap_attach to setup shared data structures that
  hold the radiotap header for each packet tx/rx
o remove rx timestamp from the rx path; it was used only by the tdma support
  for debugging and was mostly useless due to it being 32-bits and mostly
  unavailable
o track DLT_IEEE80211_RADIO bpf attachments and maintain per-vap and
  per-com state when there are active taps
o track the number of monitor mode vaps
o use bpf tap and monitor mode vap state to decide when to collect radiotap
  state and dispatch frames; drivers no longer explicitly directly check
  bpf state or use bpf calls to tap frames
o handle radiotap state updates on channel change in net80211; drivers
  should not do this (unless they bypass net80211 which is almost always
  a mistake)
o update various drivers to be more consistent/correct in handling radiotap
o update ral to include TSF in radiotap'd frames
o add promisc mode callback to wi

Reviewed by:	cbzimmer, rpaulo, thompsa

the scan in firmware and this relies on the firmware to wake up the scan task
on completion.

net80211 can happen from the ithread and submitting the fw cmd requires
a sleepable context