This supersedes the `capnp encode` and `capnp decode` commands. It didn't make sense to add JSON to those commands since it was unclear if JSON should be thought of as the "encoded" or "decoded" format. `convert` allows mapping anything to anything.

This command is also useful for, say, converting unpacked format to packed format or vice versa, which can now be done without a schema.

The Autotools and CMake builds are almost the same, except for
the libraries not being generated as versioned libraries in CMake.

Fixing this lets Linux CMake builds be on the same level as Autotools ones.

People see files named "md5" and get worried about security issues, even though we're using it only as a *non-cryptographic* PRNG. So, I renamed the files to type-id.*, encapsulated the code better to make clear that it's only used to generate type IDs, and added comments clarifying that we're not expecting it to be collision-proof.

Fixes #482.

Projects which use Cap'n Proto require C++11, because they must be able to
compile our headers. Old gcc defaults to C++98, forcing users to manually
specify the -std=gnu++11 flag in their CMake projects. CMake 3.1
introduced the target_compile_features command which removes this
necessity by automatically communicating the C++ standard level
requirement to client projects.

Specifically, if target `kj` requires a C++11 feature publicly, then all
targets which link to `kj` will also require that C++11 feature, and get
the -std=gnu++11 flag for free. If that target is a library, such as
`kj-async`, and `kj-async` links publicly to `kj`, the requirement is also
transitive to all targets which link to `kj-async`.

Note that CMake's default behavior is to request compiler-specific
extensions, such as those provided by the -std=gnu++11 flag. You must
specifically opt out of these extensions. I'm not aware of any way to
propagate this nuance in CMake, but added a check to at least prevent
users from compiling Cap'n Proto without extensions.

With this change, the c++/samples/CMakeLists.txt will build with MinGW
with no change beyond requiring a later version of CMake.

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.

This is necessary to resolve an MSVC compile error in capability.h:

struct RawSchema;
extern const RawSchema NULL_INTERFACE_SCHEMA;
constexpr RawSchema const* schema = &NULL_INTERFACE_SCHEMA;

causes MSVC to complain that `schema` is not initialized by a constant
expression. Providing the full definition of RawSchema resolves this
spurious error, so I moved it out of generated-header-support.h and into
its own raw-schema.h.

Disallow MSVC from building the parsing code by default because the latest
stable MSVC (VS2015 Update 3) ICEs when trying to compile the `anyOfChars`
combinator.

Note that VS2015 Update 2 and VS2017 can compile the parsing code, with a
little help. To experiment with this, you can override the default
behavior with -DCAPNP_BUILD_TOOLS=ON.

autotools build does not have this option.
Capnp tools are built when CAPNP_LITE == OFF

This allows to consumers to use the same targets regardless
whether capnproto CMakeList.txt is added as subdirectory
or whether capnproto is found as package

This dependency exists in Makefile.am

Consumers of non-installed build directory don't have to manually
set include dirs.

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.

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.

The user facing API is in MessageReader and MessageBuilder

{MessageBuilder,MessageReader}::isCanonical verifies the canonicity of a
message. This is both useful for debugging and for knowing if a received
message can be used for hashes, bytewise equality, etc.

MessageBuilder::canonicalRoot(Reader) can be used to write a canonical
message on a best effort basis, and checks itself using isCanonical.
It should succeed as long as the MessageBuilder in question:
* Has a first segment which is long enough to contain the message
* Has not been used before

Tests have been added in canonicalize-test.c++ which verify that for
crafted examples of canonicalization errors, isCanonical will reject,
and for a canonicalized version of the standard test message, it will
accept.

A compatibility layer is provided to ease migration.

With CAPNP_LITE=1, the command-line tools will not be built, and the
tests cannot be built without EXTERNAL_CAPNP=1 (BUILD_TESTING=0 needs to
be set if the tests are not desired).