TX queue locking fix

Locking the TX queue of a network device in Click causes trouble in Linux kernels newer than 2.6.30.

Since commit d65bfe4, the Linux kernel's dev_queue_xmit() function is called from ToDevice::queue_packet() if the kernel version is higher than 2.6.30. It seems that dev_queue_xmit() (in net/core/dev.c) may either call HARD_TX_LOCK() for the queue by itself, or then it may call __dev_xmit_skb() which may call sch_direct_xmit() (in net/sched/sch_generic.c) which calls HARD_TX_LOCK(). Therefore, because the Linux kernel code takes care of locking the queue, that should not be done by Click. And that's what I'm trying to fix here. I've tested that my simple fix works at least in Ubuntu 12.04.1 LTS, kernel version 3.2.0-31 (patchless Click).

Seems that this bug was hiding behind another bug for some time - until commit 5b88803 fixed the interpretation of the NETIF_F_LLTX flag. However, with newer kernels, not locking the TX queue in Click happened to be the right thing to do even for drivers that don't support lockless TX (i.e., most drivers as LLTX is deprecated).