Using installed capnp tools during instead of built capnp tools
easily leads to bad results.

If CapnProto is part of cmake build, macro CAPNP_GENERATE_CPP
uses in-build capnp tools.

This change fixes `make check` target with cmake.

All tests pass except
1: [ FAIL ] exception-test.c++:30: legacy test:
    Exception/TrimSourceFilename
1: /home/brano/src/capnproto/c++/src/kj/exception-test.c++:31:
    failed: expected (trimSourceFilename(
    "/home/brano/src/capnproto/c++/src/kj/exception-test.c++"))
    == ("kj/exception-test.c++");

Not sure how to fix the test without disabling it.

Which tools should the build system use in this case?

This fixes the lib vs lib64 vs lib32 issue when installing

Other problem with cached BIN_INSTALL_DIR, LIB_INSTALL_DIR, etc options
is that changing official CMAKE_INSTALL_PREFIX variable has no effect.

This makes it a lot easier for CMake based projects to use Cap'n Proto.

Example usage:

find_package(CapnProto)
capnp_generate_cpp(FOO_SRCS FOO_HDRS foo.capnp)
add_executable(foo main.cpp ${FOO_SRCS})
target_link_libraries(foo CapnProto::capnp CapnProto::capnp-rpc)

This is a lot better than the previous variable based solution since
linking to nonexistent targets is an error whereas an empty variable
expansion (e.g. due to typos) will be silently ignored. It also makes
sure that the right compiler flags, include directories, defines and
link libraries are passed to the compiler for that target without
needing any other include_directories(), etc.

Revert "Propagate DocComments into binary schema"

Propagate DocComments into binary schema

headers: check whether CAPNP_HEADER_WARNINGS is defined

Fix building with Xcode 7.3

Add observing for urgent data to UnixEventPort::FdObserver

fixes #304

style-guide: fix isConst and UnConst examples

Problems:
* missing ; after struct declarations
* missing static for constexpr bool value
* UnConst_<T> -> UnConst_<const T>
* UnConst = -> UnConst = typename

json: integrate to build

In Sandstorm, we are encoding powerbox queries in packed base64 strings which may be placed in URL query parameters or the like. The strings are provided in interfaces called browser-side. We anticipate that some developers will prefer to specify a hardcoded string rather than generate it on-the-fly, since Cap'n Proto is not well-supported in browsers today, and anyway the developer may have no other reason to have a Cap'n Proto dependency at all, and powerbox queries are often static.

In this context, speed is irrelevant, while having a compact encoding is desirable. It felt sad to me to leave in the segment table in this context, adding redundant bytes when we want a compact encoding.

Fix uninitialized members of ListBuilder

Adding a `KJ_DASSERT` in the `setListPointer` logic flagged
non-word-multiple data sections in `INLINE_COMPOSITE` lists, which
should be impossible. This traced back to uninitialized member variables
in `ListBuilder` in the case that it was created from a null pointer.

kj/vector: add methods operator = nullptr and truncate

=nullptr releases memory

https://github.com/sandstorm-io/capnproto/issues/292

doc/cxxrpc: use getParams() in server