Configure Travis CI for Linux and OSX builds.

This is redundant since branches are usually open in order to become PRs, which get their own merged-with-master builds.

fix typo in comment

Fix bug where struct equality could ignore some pointer fields.

fix copy-pasto in recently-added test case

update method names in error messages

Fixes #174

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.