Facter FQDN resolution is incorrect on Windows

Native Facter has followed parts of the previous model on Windows when resolving network facts. Unfortunately, it would seem that the method of calculating FQDN might be errant.

FQDN Is currently a combination of hostname + domain:

• hostname is retrieved by GetComputerNameEX - in networking_resolver with the flag ComputerNameDnsHostname, which should be appropriate - note that Facter 2.x used the hostname.exe command which I believe called GetComputerName, which returns a NetBIOS name
• domain still uses an older mechanism of registry spleunking with a fallback to the DnsSuffix returned from GetAdaptersAddresses at https://github.com/puppetlabs/facter/blob/ebf3003a2492cd0ac2595d7c24be9ce7f46f872e/lib/src/facts/windows/networking_resolver.cc#L202

FQDN is later calculated by concatenating these 2 pieces of data at https://github.com/puppetlabs/facter/blob/89550ef649866692afff9c7bd94044fe6c67cf4c/lib/src/facts/resolvers/networking_resolver.cc#L48-L51

This might be correct, but a better way of doing this is likely to use GetComputerNameEx with a COMPUTER_NAME_FORMAT of ComputerNameDnsFullyQualified, given the registry parsing / interface spelunking is more complicated than necessary.

When I first ran across this code, I didn't realize that Native Facter was at least using the DNS host name resolution in GetComputerNameEx, and had suggested that Facter might want to use the Winsock gethostname function. This was a bad suggestion given GetComputerNameEx can handle DNS hostnames, and given gethostname may return a hostname or FQDN based on implementation details, which make it a less attractive solution.

Not sure if it's worth changing Facter 2.x, which uses Netbios name + DNS domain name to calculate a FQDN. That might work under a lot of circumstances, but is not accurate, given Netbios names do not have to match DNS hostnames on Windows.