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.

Re-introduce async-io.c++ containing just the default implementations of methods on the abstract interfaces.

Rename async-io.c++ to async-io-unix.c++, in preparation for factoring out common bits from async-io-win32.c++.

Fix conversion build error when building with Clang 4.0

Add getFd method to FdInputStream and FdOutputStream

These methods are useful if you're receiving a generic stream in
application code and would like to check some non-stream behavior about
the file (e.g. stat or isatty).  Of course, downcasting can fail and
code should not rely on the file descriptor being available.

handle empty structs in isCanonical()

The trick here is that you must specify the value as a separate constant with a defined type. Then, you can reference that constant where an AnyPointer is expected.

Eventually we should maybe support some sort of inline syntax that specifies a type explicitly...

Support RPC on Windows (MinGW)

A grab bag of small changes to support the MSVC port

This is required to allow the compiler to successfully instantiate a
JsonCodec::Handler<DynamicValue, Style::POINTER> using Handler's default
partial specialization for Style::POINTER. Such an instantiation is
currently only used in dead code that clang and gcc eliminate but MSVC
does not, which is why the problem was not caught until now.

Also implemented DynamicValue::Builder::as<DynamicValue>() to preserve
symmetry.

For now, I'm just guessing on appropriate values for minStack and
maxStack.