Fix capnp_generate_cpp usage of --src-prefix

Various tweaks needed by Sandstorm HTTP changes

This gives Sandstorm a way to move the membrane to a different process when desired.

Add totalSize() to list readers, like struct readers.

Extend membrane framework to make revocation easy.

I realized upon trying to use this framework in Sandstorm that proper revocation was not easy to implement as-is. It's easy enough to revoke new calls, but canceling existing calls requires implementing a custom RequestHook and such. Since revocation is arguably the most important thing one might want to do with a membrane, this should be built-in.

Change capnp compiler to use KJ filesystem API.

Also fixed a similar _MSC_VER guard that I realized was catching MinGW by accident.

The disk-backed implementations were already inherently threadsafe. Making this explicit allows callers to rely on it.

This is particularly useful for SchemaParser, which is intended to be threadsafe.

Unfortunately, our cmake build scripts have historically passed -I flags specifying both the root of the source tree and the specific subdirectory in which the .capnp file is located. This is not correct, but since people do it (including our own cmake build), we need to not fail when this happens. Instead we print a warning.

Apparently, msync()'s parameters must be page-aligned, bah.

This allows detecting when two objects point to the same underlying file.

Fix Windows: SchemaParser::parseDiskFile() expects native paths, so use Windows-style absolute paths on Windows.

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.

KJ_SWITCH_ONEOF should parenthesize its argument

This allows us to deal with Maybe<OneOf<...>> variables properly inside a KJ_IF_MAYBE block.

This file is obsoleted by the CMake config package files that the autotools build now installs. Since FindCapnProto.cmake contains an implementation of capnp_generate_cpp(), in which I just fixed a bug, this file seems like a maintenance liability  now, so I'd like to delete it.

capnp_generate_cpp() needs to import two directories by default: the src-prefix directory which houses the .capnp files being compiled (under their canonical paths), and the capnp include directory which houses capnp/rpc.capnp, capnp/schema.capnp, etc. (This latter path will necessarily be different for build-tree usage versus install-tree usage.) Before this commit, instead of importing the src-prefix, we were importing CMAKE_CURRENT_SOURCE_DIR.

Note that for capnproto's own compilation of test.capnp and friends, the src-prefix and capnp include directory will end up being the exact same directory. It turns out to be surprisingly difficult to de-duplicate them, however, because the capnp include directory is actually a CMake generator expression in order to deal with the build-tree versus install-tree issue mentioned above. So, for now, we pass two -I flags to the same directory.

Alongside the fix in capnp_generate_cpp(), I fixed the usage of it in c++/src/capnp/CMakeLists.txt by setting CAPNPC_SRC_PREFIX correctly and removing the /capnp suffix hack from CAPNPC_OUTPUT_DIR.

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.