[ath] Handle STA + AP beacon programming without stomping over HW AP beacon programming

I've been using STA+AP modes at home for a couple years now
and I've been finding and fixing a lot of weird corner cases.
This is the eventual patchset I've landed on.

• Don't force beacon resync in STA mode if we're using sw beacon tracking. This stops a variety of stomping issues when the STA VAP is reconfigured; the AP hardware beacons were being stomped on!

• Use the first AP VAP to configure beacons on, rather than the first VAP. This prevents weird behaviour in ath_beacon_config() when the hardware is being reconfigured and the STA VAP was the first one created.
• Ensure the beacon interval / timing programming is within the AR9300 HAL bounds by masking off any flags that may have been there before shifting the value up to 1/8 TUs rather than the 1 TU resolution the previous chips used.

Now I don't get weird beacon reprogramming during startup, STA state
changes and hardware recovery which showed up as HI-LARIOUS beacon
configurations and STAs that would just disconnect from the AP very
frequently.

Tested:

• AR9344/AR9380, STA and AP and STA+AP modes