I got a little carried away here.

Otherwise, using kj::newDiskFilesystem() in the plugin complains.

This required some hairy backwards-compatibility hacks as the parseDiskFile() method is widely used.

In addition to cleaner code, this has the effect of fixing a number of issues:
- Fixes #494: Windows paths are now parsed and handled a lot better. On Windows, backslashes are handled appropriately, as are absolute paths with drive letters.
- Fixes #288: Specifing a source path starting with ".." without an appropriate --src-prefix will no longer cause output files to be generated outside of the specified output directory. Instead, the output name will be based on the absolute path, and a warning will be written since this is probably not what anyone wants.
- It's no longer necessary for --src-prefix to exactly match character-for-character. Instead, the prefix and source paths are canonicalized before matching. It even works if one is relative and the other absolute.
- Relative paths are now consistently always evaluated in path space, so ".." always cancels the previous path component and the OS/filesystem never even sees that it was there. This used to be the case in some places but not others. This behavior is important for symlink-heavy source trees: the path "foo/some-symlink/.." is now always designates "foo", rather than designating the parent directory of the symlink's target.

This change does not update the code generator plugins nor the SchemaParser API. Those will come in separate commits.

Specifying input files that are not in the current directory and without specifying --src-prefix has always had pretty broken results: the compiler can actually break out of the specified output directory when creating output files! This will soon no longer be allowed.

capnp-test, when run in an out-of-tree build, currently specifies such an unprefixed input, but got away with it because it was in the errors test, which doesn't actually output anything because there are input errors. We fix it by specifying a proper --src-prefix.

These use Win32 variants if and only if compiling for Windows.

Implement KJ Filesystem API on Win32

Now that I know the actual reasoning behind the loop, I think it's not the best answer. Instead, we should retry removing the directory if it reports not-empty, but only a few times before we give up.

Yes, I'm using BTRFS now...

Windows symlinks really aren't meant to be treated like Unix symlinks, and we don't support creating symlinks anyway, so we don't even know if this code works...

Fix multiple problems with connect() on non-glibc-Linux:

1. Correctly set nonblocking flag *before* calling connect(). (On glibc-Linux, we create the socket already in nonblocking mode, so this was never an issue.)
2. FDs could be leaked if connect fails. (This applies to glibc-Linux too, although connect() would have to fail immediately without blocking, which is unusual.)

Add support for Own<void>.

It appears that MSVC treats the specialization of this templated constructor as if it were an overload, causing the selection of constructor to be ambiguous. It only does this if the second template parameter (the EnableIf) if present; otherwise the specialization works correctly.

As a work-around, I refactored the code to avoid specializing the constructor. Instead, we add a static method that encapsulates the differences, which the constructor calls.

Any Own<T> can be converted to Own<void> (or Own<const void>). The main purpose of this is to give someone a way to invoke an object's disposer without them having to know anything about the type.

Also CopyFile() doesn't preserve sparseness.

So, don't use UTF-8 literals when trying to represent invalid byte sequences. Just use standard string literals.