@kloepper pointed out a while back that every compiler you've ever heard of supports this. Plus, it's more concise, it's not prone to copy-paste errors, and it looks nicer.

At the time I wanted to remain consistent and I didn't feel like spending the time to update all my existing code. But, every time I've added a new header since I've cursed the include guard, so I finally broke down and changed it.

See: https://capnproto.org/news/2015-03-02-security-advisory-and-integer-overflow-protection.html

This commit as-is is the result of wading through two years of merge conflicts. It does not build as-is because new code added in that time hasn't been converted over.

fixes #304

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.

This prevents the compiler from reporting warnings in these headers while compiling application code. Hopefully this will stem the never-ending stream of complaints from people who enable pedantic warnings.

That is to say, whereas previously we would extend capnp::typeId<T>() to a new type by declaring a specialization of it for that type, now we instead have the type contain a nested class called _capnpPrivate which contains a `typeId` constant.

This is necessary because it is impossible to specialize a template for a type which is itself nested inside a template type. E.g. it's impossible to write a specialization `template <typename T> typeId<Foo<T>::Bar>()`; C++ simply doesn't support this. But with generics, Cap'n Proto will allow types to be nested inside templates, so we need this to work.

For portions currently copyright by Kenton (most of it), transfer copyright to Sandstorm Development Group, Inc. (Kenton's company).

The license change is practically meaningless, as MIT and BSD 2-clause are legally equivalent. However, the BSD 2-clause license is sometimes confused for its ugly siblings, BSD 3-clause and BSD 4-clause. The MIT license is more immediately recognizeable for what it is.

Rémy Blank and Jason Choy (the two non-trivial contributors) are on record as approving this change:

https://groups.google.com/d/msg/capnproto/xXDd2HUOCcc/gbe_COIuXKYJ