Various interrupt handling and RX interrupt mitigation fixes.

Various interrupt handling and RX interrupt mitigation fixes.

* The AR_ISR_RAC interrupt processing method has a subtle bug in all
  the MAC revisions (including pre-11n NICs) until AR9300v2.
  If you're unlucky, the clear phase clears an update to one of the
  secondary registers, which includes TX status.

  This shows up as a "watchdog timeout" if you're doing very low levels
  of TX traffic. If you're doing a lot of non-11n TX traffic, you'll
  end up receiving a TX interrupt from some later traffic anyway.

  But when TX'ing 11n aggregation session traffic (which -HEAD isn't yet
  doing), you may find that you're only able to TX one frame (due to
  BAW restrictions) and this may end up hitting this race condition.

  The only solution is to not use RAC and instead use AR_ISR and the
  AR_ISR_Sx registers. The bit in AR_ISR which represents the secondary
  registers are not cleared; only the AR_ISR_Sx bits are. This way
  any updates which occur between the read and subsequent write will
  stay asserted and (correctly) trigger a subsequent interrupt.

  I've tested this on the AR5416, AR9160, AR9280. I will soon test
  the AR9285 and AR9287.

* The AR_ISR TX and RX bits (and all others!) are set regardless of
  whether the contents of the AR_IMR register. So if RX mitigation is
  enabled, RXOK is going to be set in AR_ISR and it would normally set
  HAL_INT_RX.

  Fix the code to not set HAL_INT_RX when RXOK is set and RX mitigation
  is compiled in. That way the RX path isn't prematurely called.

  I would see:

  * An interrupt would come in (eg a beacon, or TX completion) where
    RXOK was set but RXINTM/RXMINT wasn't;
  * ath_rx_proc() be called - completing RX frames;
  * RXINTM/RXMINT would then fire;
  * ath_rx_proc() would then be called again but find no frames in the
    queue.

  This fixes the RX mitigation behaviour to not overly call ath_rx_proc().

* Start to flesh out more correct timer interrupt handling - it isn't
  kite/merlin specific. It's actually based on whether autosleep support
  is enabled or not.

This is sourced from my 11n TX branch and has been tested for a few weeks.

Finally, the interrupt handling change should likely be implemented
for AR5210, AR5211 and AR5212.