- Copy stable/10@296371 to releng/10.3 in preparation for 10.3-RC1
builds.
- Update newvers.sh to reflect RC1.
- Update __FreeBSD_version to reflect 10.3.
- Update default pkg(8) configuration to use the quarterly branch.

Approved by: re (implicit)

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Disable WEP hardware encryption on the AR5210, in order to allow other
encryption types.

The AR5210 only has four WEP key slots, in contrast to what the
later MACs have (ie, the keycache.) So there's no way to store a "clear"
key.

Even if the driver is taught to not allocate CLR key entries for
the AR5210, the hardware will actually attempt to decode the encrypted
frames with the (likely all 0!) WEP keys.

So for now, disable the hardware encryption entirely and just so it
all in software. That allows both WEP -and- WPA to actually work.

If someone wishes to try and make hardware WEP _but_ software WPA work,
they'll have to create a HAL capability to enable/disable hardware
encryption based on the current STA/Hostap mode. However, making
multi-vap work with one WEP and one WPA VAP will require hardware
encryption to be disabled anyway.

Extend the RX HAL API to include the RX queue identifier.

The AR93xx and later chips support two RX FIFO queues - a high and low
priority queue.

For legacy chips, just assume the queues are high priority.

This is inspired by the reference driver but is a reimplementation of
the API and code.

Replace Id keyword with FreeBSD keyword and set the svn props correctly.
No functional change.

add FreeBSD property

import ath hal

Replace most compile-time support options with linker sets for
chip and RF backend support:
o add OS_DATA_SET and OS_SET_DECLARE os requirements for setting
up linker sets
o add AH_CHIP macro for registering chip support (e.g. 5210)
o add AH_RF macro for registering RF support (e.g. 2413); note
this isn't required for single chip solutions where there's no
ambiguity (e.g. 5416/9160+2133) but for 5212 class parts it's
required because of the multi-chip solutions
o remove all uses of AH_SUPPORT_AR5210, AH_SUPPORT_AR5211, AH_SUPPORT_5212,
and AH_SUPPORT_AR9160; still need AH_SUPPORT_AR5416 to enable the 11n
descriptor formats and 5312 support is presently broken
o remove all uses of AH_SUPPORT_2133, AH_SUPPORT_2413, AH_SUPPORT_5111,
AH_SUPPORT_5112, AH_SUPPORT_2417, AH_SUPPORT_2425, and AH_SUPPORT_5413;
5312-related support still requires fixup

Remaining issues:
o fixup SoC attach
o ath_hal_attach uses a hack to probe w/o access to the vendorid
o fallback handling of parts w/o a macrev needs to be restored

virgin import of ath hal