Have AppVeyor run the tests.

I can only reproduce this failure on AppVeyor, but the test prints:

capnp\rpc.c++:2886: exception = kj\async-io-win32.c++:399: failed: WSASend(): A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call.

I think this is because WSAESHUTDOWN was considered to be a "bug" exception rather than a "disconnected" exception. It is odd, though, that it doesn't happen when I run locally.

On Linux this cuts 56% off the run time of the fuzz test (aka 2.28x speedup).

On Windows this makes it practical to run the fuzz test at all -- previously it was wayyyyyyy too slow.

While the VS2015 build no longer depends on the MinGW installation as an
external capnp, I think testing the CMake MinGW build on Windows probably
remains worthwhile.

This option was only useful when MSVC couldn't build the capnp command
line tools, so let's back it out.

The previous solution used hard-coded paths which would have had to be
special-cased for multi-configuration generators such as Visual Studio,
which put binaries in individual Debug, Release, etc. directories.

MSVC as of VS2015 does not initialize the vtable pointers of constexpr
objects, causing nullptr dereferences at runtime. To solve this, we can
just convert them to regular const variables with internal (static)
linkage.

The internal linkage bit is important: as long as they are invisible
outside their respective translation units, we do not risk the static
initialization order fiasco.  If we ever need to reference them outside
their translation units, we would need to hide them behind functions (like
HeapArrayDisposer::instance()) to keep things safe.

This works around an issue which prevented kj::parse::ref() from compiling.

The fix in ae6b4452 worked for getting the HTTP code building, but was
apparently insufficient for the capnp command line tools.

This is currently passing.

This is currently passing.

Add kj-http to cmake build.

Apparently the test has accidentally been using the installed capnp all along.

Fixes #196

Bug fix rollup for 0.6 release

Fixes #212

Specifically, consider:

    capnp::BuilderFor<capnp::DynamicStruct> capnp::Orphan<capnp::AnyPointer>::getAs<capnp::DynamicStruct>(capnp::StructSchema)

Note that `BuilderFor` is a "template using" directive which expands into something more complicated.

GCC mangles the symbol as:

    _ZN5capnp6OrphanINS_10AnyPointerEE5getAsINS_13DynamicStructEEENS_11BuilderFor_IT_Xcl4kindIS6_EEEE4TypeENS_12StructSchemaE

Which `c++filt` decodes as:

    capnp::BuilderFor_<capnp::DynamicStruct, (kind<capnp::DynamicStruct>)()>::Type capnp::Orphan<capnp::AnyPointer>::getAs<capnp::DynamicStruct>(capnp::StructSchema)

Note that `BuilderFor_<...>::Type` here ends up being a typedef for `DynamicStruct::Builder`. It seems weird to me that the symbol name would not substitute this typedef.

Clang, meanwhile, mangles the symbol as:

    _ZN5capnp6OrphanINS_10AnyPointerEE5getAsINS_13DynamicStructEEENS_11BuilderFor_IT_Xclgssr5capnpE4kindIS6_EEEE4TypeENS_12StructSchemaE

Which `c++filt` does not seem to be able to demangle at all. But, it looks like `capnp::kind` is in there, suggesting that, again, the typedef wasn't substituted.

I don't know who is right, but if we inline the whole thing, the problem goes away.

Fixes #251

Fixes #336