Isolate Windows codebase from UN*X systems

[lorentey]

We keep breaking the Windows port whenever we land a new feature for Darwin and/or Linux. This needs to stop.

There is absolutely no reason the Windows port of swift-system needs to be built from the same sources (or provide the same APIs) as UN*X systems; in fact, this is detrimental to the objective of this project and only serves to make it more difficult/error-prone to maintain this package. To a lesser extent, this is also true of Linux vs Darwin.

• Set up platform-specific directories under Sources/ and Tests/. Explicitly exclude source files that wrap POSIX/Darwin/Linux syscalls from the Windows build, and vice versa.
• For cases where code sharing across platforms actually makes sense (i.e. some POSIX calls on Linux & Darwin), set up a POSIX/ platform directory, and include the sources therein in both the Darwin and Linux builds. If we want to keep some parts of the implementation of FilePath shared across all platforms, then move those parts into a shared/ or common/ subdirectory.
• Just like the actual build, tests are platform specific, and they need to be configured accordingly. The test suite in this package is currently completely broken on Windows.
• Never, ever, pretend that Windows implements POSIX system calls.

[Jumhyn]

The test suite in this package is currently completely broken on Windows.

Is this why Windows is not currently part of the PR checks for this repo? That seems to me like the most obvious near-term way to avoid breaking the Windows port. Also, until Windows is part of the regular PR checks, it seems to me like there should be some notes in the documentation about what the status of this project is with respect to Windows.

That might take the form of:

• Elaborating in the README on how close swift-system is to the "vision" described of being the home for system interfaces "for all supported Swift platforms"—is Windows currently considered a supported platform for swift-system?
• Explicitly noting in the README that there is a lower stability guarantee for Windows than there is for other platforms, and encourage users on Windows to pin to a specific release
• Describing in CONTRIBUTING.md exactly what the expectations are with respect to testing that the Windows port

[compnerd]

I have a series of patches that I hope to finish uploading soon. That at least makes the test suite build; there are a few failures and one of them is particularly worrisome (assertion failure in FilePath).

[lorentey]

Scheduling for 1.4.0; I think it's time to do this.

[jakepetroules]

#227 just enabled CI for Windows, so I think that alone should generally resolve the issue of constantly breaking the build.