Also, push harder on the code generator such that `StreamResult` doesn't show up in generated code at all.

So now we have `StreamingRequest<Params>` which is like `Request<Params, Results>`, and we have `StreamingCallContext<Params>` which is like `CallContext<Params, Results>`.

There are two things that every capability server must implement:

* When a streaming method is delivered, it blocks subsequent calls on the same capability. Although not strictly needed to achieve flow control, this simplifies the implementation of streaming servers -- many would otherwise need to implement such serialization manually.
* When a streaming method throws, all subsequent calls also throw the same exception. This is important because exceptions thrown by a streaming call might not actually be delivered to a client, since the client doesn't necessarily wait for the results before making the next call. Again, a streaming server could implement this manually, but almost all streaming servers will likely need it, and this makes things easier.

Note: Apparently, json.capnp had not been added to the bootstrap test, and the checked-in bootstrap had drifted from the source file.

This can be used on a method to indicate that it is used for "streaming", like:

    write @0 (bytes :Data) -> stream;

A "streaming" method is one which is expected to be called many times to transmit an ordered stream of items. For best throughput, it is often necessary to make multiple overlapping calls, so as not to wait for a round trip for every item. However, to avoid excess buffering, it may be necessary to apply backpressure by having the client limit the total number of overlapping calls. This logic is difficult to get right at the application level, so making it a language feature gives us the opportunity to implement it in the RPC layer.

We can, however, do it in a way that is backwards-compatible with implementations that don't support it. The above declaration is equivalent to:

    write @0 (bytes :Data) -> import "/capnp/stream.capnp".StreamResult;

RPC implementations that don't explicitly support streaming can thus instead leave it up to the application to handle.

On Windows executables needs to end with .exe.
Fix this in CMakeLists.txt and update capnp detection code accordingly.

If we were using C++17, we could use [[fallthrough]] instead... but we are not.

So far this is only a small subset of all the STL uses.

Fixes #487
Fixes #695

I was shocked to find that there was no good way to represent a multi-line literal currently. This implements C-style literals, where multiple consecutive string literals are concatenated.

MinGW 7.2 (x86_64) build failed

Various versions of MSVC have various troubles deducing the Kind K of a List<T, K>. This change removes any need for the compiler to deduce the Kind, and just hard-codes it into the generated code.

Fixes #642.

@kloepper pointed out a while back that every compiler you've ever heard of supports this. Plus, it's more concise, it's not prone to copy-paste errors, and it looks nicer.

At the time I wanted to remain consistent and I didn't feel like spending the time to update all my existing code. But, every time I've added a new header since I've cursed the include guard, so I finally broke down and changed it.

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.

I got a little carried away here.

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

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.

before including windows.h.

Visual Studio 2017 (14.11.25503, 19.11.25508.2) needs `#include <wincrypt.h>` for CryptGenRandom etc.

This supersedes the `capnp encode` and `capnp decode` commands. It didn't make sense to add JSON to those commands since it was unclear if JSON should be thought of as the "encoded" or "decoded" format. `convert` allows mapping anything to anything.

This command is also useful for, say, converting unpacked format to packed format or vice versa, which can now be done without a schema.