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

This eliminates a TODO(soon).

This allows functions which use KJ_EXPECT and other test macros to be built without linking libkj-test, which pulls in a possibly-unwanted main() function.

In particular, afl-testcase.c++ could not link in -fno-exceptions mode without this change.

doc/cxxrpc: Document lazy execution

The previous approach worked only for ekam builds, where fuzz-test was its own binary.