Make sure to clear tag word when upgrading a struct list.

Edit error message for the case where copyPointer() hits a FAR pointer.

The existing error message suggests this case can only arise if there is a
a bug in the library. However, malformed input can trigger the error too.
In particular, the error gets thrown when a non-double far pointer resolves
to another far pointer.

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.