Let nping work with --unprivileged on Windows

[dmiller-nmap]

Right now, --unprivileged implies inability to use pcap. But on Linux, the same is true and yet it falls back to TCP Connect mode without problems. Windows should do the same, which would also allow it to be used without Npcap/WinPcap if it's not available in some strange circumstance.

[dmiller-nmap]

The behavior experienced is:

• "WARNING: Could not import all necessary Npcap functions." from winfix.cc. This is the result of some exception being raised, but I can't see how it would happen. Nmap has no such problem, but has a slightly different code to load the Npcap dlls.
• "Nping requires that WinPcap version 3.1" etc. from NpingOps.cc. This check should be bypassed for modes that do not actually require PCAP functions.

In reality, the check for having Npcap/WinPcap in validate_options should not be present at all. We already setIsRoot(0) if loading Npcap fails in winfix.cc, so the logic that already exists for checking root privilege on Linux will be valid on Windows as well. The check for have_pcap on other systems isn't even valid, since it's not set anywhere. We could replace the whole have_pcap/setHavePcap/havePcap mess with a single local boolean in win_init and cut out all the related code elsewhere.

[Varunram]

Was looking into a fix and encountered the following issues.

1. Since have_pcap is a private bool, we need to have the relevant functions (setHavePcap, havePcap) to query the class about the variable's status. By removing these, we would essentially be altering how we access have_pcap in the class NpingOps. Is this desirable?

2. If we do use a boolean in win_init, we would again be querying the class regarding setHavePcap since we can't access have_pcap directly.

Maybe we could have a separate variable, (say havePcap) use this in win_init and somehow find a way around having to query the private member have_pcap (or maybe drop it entirely in favour of havePcap)?