[ath] fix thresholds for deciding to queue to the software queue and populate hardware frames

This is two fixes, which establishes what I /think/ is pretty close to the
theoretical PHY maximum speed on the AR9380 devices.

• When doing A-MPDU on a TID, don't queue to the hardware directly if the hardware queue is busy. This gives us time to get more packets queued up (and the hardware is busy, so there's no point in queuing more to the hardware right now) to potentially form an A-MPDU.
  
  This fixes up the throughput issue I was seeing where a couple hundred single frames were being sent a second interspersed between A-MPDU frames. It just happened that the software queue had exactly one frame in it at that point. Queuing it until the hardware finishes transmitting isn't exactly costly.

• When determining whether to dequeue from a software node/TID queue into the hardware queue, fix up the checks to work right for EDMA chips (ar9380 and later.) Before it was not dispatching anything until the FIFO was empty. Now we allow it to dispatch another aggregate up to the hardware aggregate limit, like I intended with the earlier work.

This allows a 5GHz HT40, short-GI, "htprotmode off" test at MCS23
to achieve 357 Mbit/sec in a one-way UDP test. The stars have to be
aligned /just right/ so there are no retries but it can happen.
Just don't expect it to work in an OTA test if your 2yo is running
around the room - MCS23 is very very sensitive to channel conditions.

Tested:

• AR9380 STA (test) -> AR9580 hostap

TODO:

• More thorough testing on pre-AR9380 chips (AR5416, AR9160, AR9280)
• (Finally) teach ath_rate_sample about throughput/latency rather than air time, so I can get good transmit rates with a 2yo running around.