First pass of adding transmit parameters as an option for outbound

First pass of adding transmit parameters as an option for outbound
802.11 mbufs.

The raw transmit path currently doesn't make it easy to queue
these frames:

* there's no node reference stored in the mbuf, like for the normal
  path, and
* the bpf supplied raw transmit parameters (rate, rts/cts, etc)
  are passed in as an argument, not as an mbuf tag.

In order to support driver queuing of these frames, we need to
be able to put the above into the mbuf before the driver gets it,
so the driver /can/ put it into a queue if needed.

Use an mbuf tag and for now just verbatim copy the bpf parameters
into it.  Later on it may grow to include more options but this
will do for now.

Why would you want to queue raw frames? Well, in the case of
iwn(4), we can't send the firmware frames to transmit before
we hear a beacon - the firmware will consider passive channels
as unavailable until it hears a beacon.  The firmware "passive"
channel state is cleared upon each RXON command, which is sent to
update association status.  So, when we attempt association and
authorisation, the RXON command causes the firmware to clear out
what it's already seen, and so we have to wait for a beacon before
we can transmit.

Before people get overly excited - this alone doesn't "fix" 5GHz
operation - it just makes it (more) possible.

The aim here is to convert all the drivers over to use a raw_xmit()
API that doesn't include the node and params - instead they'd get
those from the mbuf.  Then raw_xmit() becomes just a side-channel
version of the normal transmit path for management traffic.

MFC after:	2 weeks
Sponsored by:	Norse Corp, Inc.