fix bug in parsing of non-ascii constants

Fix MSVC build errors

Closes #408. Perhaps the same bug as in commit cff9ba05?

Add HTTP client and server implementation.

The old semantics were intended to allow more implementation freedom, but I find in my actual code it's very convenient to rely on the actual implementation details. Other implementations will just have to deal with it.

Let MSVC build without lite mode

Bootstrap regeneration commit to follow.

Although bootstrap regeneration will basically be a no-op (no bootstraps
have deeply nested generics which this commit fixes), one will follow this
commit for completeness.

MSVC cannot deduce sizes of arrays defined inside class templates.

Bootstrap regeneration commit to follow.

MSVC erroneously refuses to compile code which calculates the address of
objects of static storage duration at compile-time, despite this being
legal. Work around this by changing `_capnpPrivate::brand` from constexpr
pointers to static constexpr functions returning pointers. The compiler
is then free to calculate it at compile-time if it can (gcc, clang), but
can also defer it to run-time if it can't (MSVC).

This change is split into three commits:

1. Changes to the code generator (this commit).
2. A bootstrap regeneration, after which the codebase will not compile.
3. Changes to the generated code support header, after which the codebase
will again compile.

MSVC refuses the following code:

struct Foo { Foo(Foo&) {} };
Foo foo;
[foo] {}();

because it only seems to want to consider const copy constructors when
capturing objects by value in lambda capture lists.

We could also port this by using the deprecated MSVC compiler intrinsics,
but:

1) They're deprecated,
2) I've never used them,
3) We'd need to sprinkle some #if's in the code to support both MinGW and
MSVC, increasing the maintenance burden.

Reads and writes of volatile aligned words are automatically blessed with
atomic acquire and release semantics at compile-time by MSVC, leaving only
CPU operation reordering to worry about. x86 and x64 CPUs will not reorder
the operations, but MSVC targets Xbox, which notably will reorder them,
thus I added fences out of an abundance of caution. While Cap'n Proto
likely will not compile for Xbox as-is, I would hate for someone to port
it only to have to debug obscure atomic-operation-related crashes later.

I implemented the fences using std::atomic_thread_fence rather than
MemoryBarrier(), because including windows.h in raw-schema.h is a
non-starter, and it would be silly to reimplement it with in-line assembly
and intrinsics for every targeted CPU when <atomic> is available.

Another possible implementation could have been to use the InterlockedXxx
functions, however they present a few issues:

1. They're defined in windows.h. We could define them in terms of their
   underlying _InterlockedXxx intrinsics, but we'd need more #if blocks to
   handle both 32-bit and 64-bit pointers. If we go this route, it'd
   probably be better to go all-in and define some kj::atomic{Load,Store}
   functions.
2. We cannot implement atomic load-acquire semantics with them for const
   variables without const_casting.

This is necessary to resolve an MSVC compile error in capability.h:

struct RawSchema;
extern const RawSchema NULL_INTERFACE_SCHEMA;
constexpr RawSchema const* schema = &NULL_INTERFACE_SCHEMA;

causes MSVC to complain that `schema` is not initialized by a constant
expression. Providing the full definition of RawSchema resolves this
spurious error, so I moved it out of generated-header-support.h and into
its own raw-schema.h.

The calling convention must go inside the parentheses when declaring a
function pointer.

WINBOOL is apparently a MinGW-ism.

Disallow MSVC from building the parsing code by default because the latest
stable MSVC (VS2015 Update 3) ICEs when trying to compile the `anyOfChars`
combinator.

Note that VS2015 Update 2 and VS2017 can compile the parsing code, with a
little help. To experiment with this, you can override the default
behavior with -DCAPNP_BUILD_TOOLS=ON.

Properties:
- Presented as a LIBRARY, designed to be unopinionated about the application using it.
- Uses KJ async framework.
- Header parsing is zero-copy. The whole header block is read into a contiguous buffer, then parsed all at once. Avoids complicated state machinery (and is probably pretty fast).
- Known headers are parsed to numeric identifiers so that the application doesn't need to look them up by string name. The app registers all headers it is interested in upfront, receiving numeric IDs for each. Some common headers also have pre-defined constants, avoiding the need for registration.
- Connection-level headers (e.g. Content-Length, Transfer-Encoding) are handled entirely internally.
- WebSocket support (planned).

Not done yet:
- Implement the version of HttpClient that connects to new servers as-needed, managing a pool of connections. Currently I've only implemented the version that takes a pre-existing connection and speaks HTTP on it.
- Implement WebSockets.
- Implement plugable transfer encodings (although I guess Chrome doesn't even support transfer encodings other than chunked; maybe it's a lost cause).
- Implement HTTP/2, hopefully transparently (... someday).