ProcessInfo.processInfo.environment returns magic shell environment vars which aren't valid

[jakepetroules]

Here's an excerpt of what ProcessInfo.processInfo.environment returns for me:

=C:=C:\Users\jakepetroules
=E:=E:\test2
=ExitCode=00000001
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\jakepetroules\AppData\Roaming

This is (apparently) because the GetEnvironmentStringsW API can return magic environment variables set by the cmd shell which aren't in fact valid environment variables.

They won't be shown by set, and the documentation doesn't say anything about these magic variables, but does say The name of an environment variable cannot include an equal sign (=).

I believe we should consider dropping any environment variable strings returned by GetEnvironmentStringsW which start with the = character, to avoid surprising behavior.

This is what Qt did back in 2013: https://github.com/qt/qtbase/commit/e7a242b27b961c64613542c75c69954d1c7bd315, maybe we should check also what some other languages/environments are doing as well, like .NET or Python.

[jmschonfeld]

I think we'll probably want to do this, because the old implementation in SCL-F did this before. SCL-F has the following test:

let env = ProcessInfo.processInfo.environment

XCTAssertNil(env[""])

Which currently fails on Windows and now that we're getting testing up and running on Windows we'll want to resolve that one way or the other.