I think this is worthwhile since otherwise this header can't be used at all on MSVC, which has all sorts of sad downstream effects. Hopefully we can revert this soon, when MSVC gets fixed.

adjust AnyList::equals(): a list of pointers cannot be equal to a struct list

I did run them once and they passed. It took a very long time.

Otherwise, the HTTP client might be destroyed before it has written all data, since the responses have already been received.

In particular this fixes http-test on Win32.

Add initial AppVeyor support

canonicalization: make sure that pad bits of primitive lists are zeroed

ignore pad bits when checking for bit list equality

This AppVeyor configuration will do the following:

1. Download MinGW 4.8.5, if it doesn't already have it.
2. Build and install the entire project with MinGW.
3. Build and install everything that MSVC can build, using the MinGW external
   capnp tools.
4. Build the contents of c++/samples.
5. Zip up the contents of each install directory, which will be available for
   download as artifacts.

AppVeyor will autoconfigure itself if it sees this file, so you should
just have to:

1. Log into ci.appveyor.com. You can use a GitHub account for this.
2. Select "New Project."
3. Select capnproto from the list of GitHub projects.

Push to any branch, and AppVeyor should automatically build the new
commit. If you want to build a branch that you've already uploaded, you
can change the default branch in 'Settings -> General', then start a
manual build.

I used Dr. MinGW's appveyor.yml as a template for the MinGW download and
extraction code:
https://github.com/jrfonseca/drmingw/blob/2340928f5cbc0ba718e8dd160e027af7722383c8/appveyor.yml

Microsoft only implements putenv, which has a slightly different syntax.

This change allows CMake to build the entire project on Windows with MinGW
4.8.5.

Build samples with MSVC

Or... negato?

When building Cap'n Proto with compilers which can't yet build the command
line tools (MSVC), the exported targets capnp_tool and capnpc_cpp don't
exist, thus attempting to use them in a generator expression when setting
CAPNP_EXECUTABLE and CAPNPC_CXX_EXECUTABLE causes a hard error.

Leaving the variables unset provides users the opportunity to set
CAPNP_EXECUTABLE and CAPNPC_CXX_EXECUTABLE manually in CMake projects
consuming Cap'n Proto as a CMake package, and produces a less mystifying
error message if the user forgets.

Thanks to Philip Quinn for advice on this issue.

Fixes a recently introduced build error on Windows.

Microsoft's docs say to include either <process.h> or <stdlib.h>. I
arbitrarily chose process.h.

Refactor bounds checks to avoid ever creating out-of-bounds pointer values, which is technically UB even if not dereferenced.

Details: https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2017-04-17-0-apple-32bit-elides-bounds-check.md

MallocMessageBuilder: don't allocate segments above the max serializable size

Fix autotools build on MacOS