Out-of-bounds references due to hacks that try to figure out if a string is in the local code page or in UTF-16LE

WinPcap 4.1.1 added a hack to the adapter open path to work around pcap_lookupdev() returning UTF-16LE strings rather than ASCII strings for device names.

The hack attempts to check whether the device name string is ASCII (local code page) or UTF-16LE by checking whether the first byte is non-zero and the second byte is zero. If that's the case, it's treated as a UTF-16LE null-terminated string.

Unfortunately, a one-character ASCII string can't be distinguished from the first byte of a UTF-16LE string, and if you mis-identify a one-character ASCII string as a UTF-16LE string, you'll go past the end of the string when processing it as a UTF-16LE string.

The comment from WinPcap 4.1.1 is

	 * This wonderful hack is needed because pcap_lookupdev still returns
	 * unicode strings, and it's used by windump when no device is specified
	 * in the command line

Tcpdump, however, uses pcap_findalldevs() if it's available, picking the first interface from the list, so this bug no longer affects it, and pcap_lookupdev() is now marked as deprecated. It always returns ASCII device names, so programs using pcap_findalldevs() don't require this workaround.

If binary compatibility with programs using pcap_lookupdev() to find a default interface can be dropped in Npcap, the hack can be dropped as well.

Start at the adapter open path and inspect the UTF-16LE detection hack around pcap_lookupdev(). Compare its compatibility requirements with pcap_findalldevs() and the stated ASCII behavior. Done means determining whether pcap_lookupdev() compatibility can be dropped and whether the unsafe workaround can consequently be removed.