Packet.dll routines should report errors if the service can't be started or the helper process can't be run

I was trying to debug a problem where libpcap's findalldevstest program wasn't returning any interfaces; the problem is that I needed to copy the helper executable into the run/Debug subdirectory of my libpcap build directory.

If:

• NpcapStartHelper() were to return FALSE if the helper needed to be started but couldn't be started, and TRUE otherwise;
• PacketOpenAdapterNPF() were to return NULL if NpcapStartHelper()` returned FALSE;
• PacketAddAdapterIPH() and PacketAddAdapterNPF() were to return FALSE for PacketOpenAdapterNPF() returning NULL and the error being any of the ShellExecuteExA() errors that mean "the helper couldn't be started" rather than meaning "there is no such adapter";
• PacketGetAdaptersIPH(), PacketGetAdaptersNPF(), and PacketUpdateAdInfo() were to return FALSE if the corresponding PacketAddAdapterXXX() routine failed with one of those errors;
• PacketPopulateAdaptersInfoList() were to do the same, and return a success/failure Boolean;

that would, I think, allow this.

This would also allow pcap_activate_npf() to return PCAP_ERROR_PERM_DENIED if a program tries to open an adapter, Npcap is in admin-only mode, and the user says "No" to the UAC prompt - and would also allow any future device-enumerating APIs to do so as well.

Start with findalldevstest and trace NpcapStartHelper(), PacketOpenAdapterNPF(), the PacketAddAdapterXXX(), PacketGetAdaptersXXX(), PacketUpdateAdInfo(), and PacketPopulateAdaptersInfoList() routines. Review how ShellExecuteExA() failures are currently handled. Done means helper-start failures propagate through adapter enumeration and pcap_activate_npf() can report permission denial when the UAC prompt is declined.