Support Windows Server versions

[dbwiddis]

The current implementation only includes "NT Workstation" (e.g., personal) versions and doesn't work for Windows Server versions. See JDK Source for a list of possible values for the os.name property.

There are a few tricky points to consider here:

• Some server versions are the same as the corresponding workstation version and for the purpose of matching versions, should match. For example, Vista and Server 2008 have the same feature set, so could possibly share the same enum value.
• But sharing the enum may not work for Server 2016 vs. Server 2019 where there's a distinction based on the build number
• If we do have separate enums for server version that introduces a question on how to handle the isAtLeast() checks based on enum ordering; indicating perhaps we should be keeping major/minor available for this check. But that's hard without exposing it to the API.
• Taking a look at the official Windows API for comparing versions, however, they don't handle the servers separately, they stick with essentially the same enum list you have, suggesting that for isAtLeast() the existing enum ordering is sufficient and we should just add the server versions as equivalent case staements, e.g., map "server 2008" to "vista" and so on, and consider Server 2016 and Server 2019 equivalent.

[cegredev]

This is another reason for a better/more flexible versioning system than having a separate enum value for every iteration. I'm hoping to get on that in the next couple of days. Thanks a lot for the info and resources!

[dbwiddis]

On the theme of WIndows version numbers needing build numbers, and on the heels of #4 which was the first to release a version "11" under a "10" label... Windows 11 can also show up as WIndows 10 with a build number of 22000+. So this particular issue should probably take a higher priority now. :)