Add Windows Support

[Will-Low]

Situation

Currently, there is no Windows support. Windows support would require ironing out a few details:

1. Handling case-insensitivity of environment variables.
2. Determining whether Windows environment variables can cause the Values::NotUnicode error and how that would look like. The tests for invalid UTF-8 would need to be adjusted accordingly.

Target

Add support for Windows.

Proposal

TBD

[ChrisDenton]

For reference, here's what I know about the Windows environment (sorry if this info dump is overwhelming, I can clarify if needed):

• Environment keys are case-insensitive but case-preserving. For example, the first time you set the key "Rust" it'll be stored just like that. But if you then set a key called "ruST" it'll set "Rust".
• Like most strings in Windows, environment variables are stored as a UTF-16 string. However, no checking is done for illegal UTF-16 (aka unpaired surrogates, to use the technical term). So it is possible for someone to screw with them.
• Case-insensitive comparisons are done by upper casing strings. However, to do it the same way as the OS is slightly tricky as they may differ slightly from standard Unicode casing and in any case can change between Windows versions. Therefore, ideally, OS functions should be used for this. However this does require converting strings to UTF-16 and back (both Rust's String and OsString, on Windows, have methods for this depending on how you want to handle it).
• Related OS functions include:
  • To convert UTF-16 to uppercase, use LCMapStringEx with lpLocaleName set to LOCALE_NAME_INVARIANT and dwMapFlags to LCMAP_UPPERCASE.
  • Test two UTF-16 case-insensitively using CompareStringOrdinal.
• You can almost certainly get away with just doing the obvious thing if the key is ASCII only (e.g. str::eq_ignore_ascii_case). Or if you know the characters used in the string comes from a language that uses symbols rather than an alphabet (but that's more complex to check).