Some non-802.11e non-standard conforming APs use seperate TX sequences

Some non-802.11e non-standard conforming APs use seperate TX sequences
for non-beacon frames and beacons.  If local cache of <addr2,seq,fragno>
tuple is updated when beacons from such kind of AP are received, 802.11
duplication detection mechanism may decide to discard non-beacon retry
frames if its sequence is less than or equal to just received beacon's.
Together with the poor TX rate control algorithm chosen by these kinds
of APs, i.e. a lot of retry data frames, a TCP connection can be choked
by STA's duplication detection mechanism.

To handle these kinds of APs (yep, we are in the world of compat):
Don't update cache of <addr2,seq,fragno> tuple for multicast or broadcast
802.11 MAC frames.  This does not violate IEEE Std 802.11, 1999 Edition
subclause 9.2.9, which actually allows us to "omit tuples obtained from
broadcast/multicast ...".

Thank Petr Janda <elekktretterr@exemail.com.au> for providing all
necessary 802.11 tcpdumps to track down the problem.

Thank dillon@ for analyzing some tcpdumps which leads me to think that
the reported problem may be caused by the duplication detection in
802.11 layer.

Reported-by: Petr Janda <elekktretterr@exemail.com.au>
Tested-by: Petr Janda <elekktretterr@exemail.com.au>