Forced de-auth: include existing monitor mode adapters in the dropdown, but remove the (non-monitor-mode) adapter currently selected for capture

[poser]

If a WiFi adapter can send a de-auth packet, its monitor mode adapter can still do so even while being used simultaneously as the capture interface (at least for the drivers we've tested so far). So, there's no reason to spawn an additional monitor mode interface on the adapter currently being used to sniff (that is, the one selected in the first adapter dropdown). Of course, if a different adapter is selected, we will still need to spawn the monitor mode interface.

So:

• Exclude from the second WiFi adapter dropdown whatever is currently selected in the first WiFi adapter dropdown,
• Include in the second WiFi adapter dropdown the monitor mode interface currently being used for capture.

[poser]

As is, attempting to select the adapter from which we spawned the monitor mode interface being used for capture produces... Interface wlanX already in monitor mode on channel Z. ...rather than, as I'd assumed, spawning an additional monitor mode interface.

[poser]

Perhaps it was the resolution of other, related bugs, but this now appears to work in a more acceptable way. Specifically, selecting an adapter that has already spawned a monitor mode interface now appears to use that monitor mode interface. (Albeit only if the the application itself spawned the monitor mode interface when the demo was started? If airmon-ng was used, outside of the application, to spawn mon0 from wlan0, for example, then selecting wlan0 appears to spawn mon1 rather than recognizing the existence of mon0 and using it.)

Regardless, this seems acceptable (at least for now).