@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.

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.

Specifically, consider:

    capnp::BuilderFor<capnp::DynamicStruct> capnp::Orphan<capnp::AnyPointer>::getAs<capnp::DynamicStruct>(capnp::StructSchema)

Note that `BuilderFor` is a "template using" directive which expands into something more complicated.

GCC mangles the symbol as:

    _ZN5capnp6OrphanINS_10AnyPointerEE5getAsINS_13DynamicStructEEENS_11BuilderFor_IT_Xcl4kindIS6_EEEE4TypeENS_12StructSchemaE

Which `c++filt` decodes as:

    capnp::BuilderFor_<capnp::DynamicStruct, (kind<capnp::DynamicStruct>)()>::Type capnp::Orphan<capnp::AnyPointer>::getAs<capnp::DynamicStruct>(capnp::StructSchema)

Note that `BuilderFor_<...>::Type` here ends up being a typedef for `DynamicStruct::Builder`. It seems weird to me that the symbol name would not substitute this typedef.

Clang, meanwhile, mangles the symbol as:

    _ZN5capnp6OrphanINS_10AnyPointerEE5getAsINS_13DynamicStructEEENS_11BuilderFor_IT_Xclgssr5capnpE4kindIS6_EEEE4TypeENS_12StructSchemaE

Which `c++filt` does not seem to be able to demangle at all. But, it looks like `capnp::kind` is in there, suggesting that, again, the typedef wasn't substituted.

I don't know who is right, but if we inline the whole thing, the problem goes away.

TODO:
- Rename Guarded to Bounded?
- Consider bounded array (where size and indexes are bounded quantities).
- Implement non-CAPNP_DEBUG_TYPES fallback.
  - Don't allow casting kj::maxValue to bounded type, this won't work right when not using debug types!
- Verify that this change doesn't hurt performance.

This is required to allow the compiler to successfully instantiate a
JsonCodec::Handler<DynamicValue, Style::POINTER> using Handler's default
partial specialization for Style::POINTER. Such an instantiation is
currently only used in dead code that clang and gcc eliminate but MSVC
does not, which is why the problem was not caught until now.

Also implemented DynamicValue::Builder::as<DynamicValue>() to preserve
symmetry.

Problem discovered and initial test case contributed by Harris Hancock.

fixes #304

The library allows for registering special handlers for specific types or fields. This is particluarly useful for overriding the way `Data` is encoded (since many approaches exist) or supporting encodings like EJSON or Q which extend JSON with special types encoded as objects with field names perfixed by dollar signs.

Not integrated into build system yet (but builds nicely with Ekam). I think this is going to need to be a separate library, e.g. libcapnp-json, because clearly a lot of Cap'n Proto users don't need it at all.

For the moment, this was written for use inside Sandstorm. There is no current need for a decoder, so I have not written that yet and have no immediate plans to do so. But it will be added before any official Cap'n Proto release, certainly. A simple recursive descent parser should be easy...

**The problem**

The methods MessageReader::initCapTable() and MessageBuilder::getCapTable() always felt rather hacky. initCapTable() in particular feels like something that should be handled by the constructor. However, in practice, the cap table is often initialized based on a table encoded within the message itself. That is, an RPC message contains a "payload" which includes both the application-level message structure and a table of capabilities. The cap table has to be processed first, then initCapTable() is called on the overall message, before the application structure can safely be read.

The really weird part about this is that even though the cap table only applies to one branch of the message (the payload), it is set on the *whole* MessageReader. This implies, for example, that it would be impossible to have a message that contains multiple payloads. We haven't had any need for such a thing, but an implemnetation that has such artificial limitations feels very wrong.

MessageBuilder has similar issues going in the opposite direction.

All of this ugliness potentially gets worse when we introduce "membranes". We want a way to intercept capabilities as they are being read from or written to an RPC payload. Currently, the only plausible way to do that is, again, to apply a transformation to all capabilities in the message. In practice it seems like this would work out OK, but it again feels wrong -- we really want to take a single Reader or Builder and "wrap" it so that transformations are applied on capabilities read/written through it.

**The solution**

This change fixes the problem by adding a new pointer to each struct/list Reader/Builder that tracks the current cap table. So, now a Reader or Builder for a particular sub-object can be "imbued" with a cap table without affecting any other existing Readers/Builders pointing into the same message. The cap table is inherited by child Readers/Builders obtained through the original one.

This approach matches up nicely with membranes, which should make their implementation nice and clean.

This change unfortunately means that Readers and Builders are now bigger, possibly with some performance impact.

Fix bug where calling a list setter using a list obtained from a similarly-typed getter, but where the underlying pointer was null, would write an incorrectly-typed pointer in the destination (specifically, an empty List(Void)). Now it sets an empty list of the correct type.

Also fix AnyStruct::Reader/Builder as methods

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

Fix bug where receiving EOF on the RPC connection could cause RpcConnectionState to go into an infinite promise loop.  Strange that this did not cause trouble earlier.  Also some minor tweaks.

Extend totalSizeInWords() to also return a count of capabilities, which helps when a separate capability table needs to be allocated as well.  Use this in the RPC system.

Revamp concurrency model, part 1:  EventLoop no longer allows cross-thread event queuing, simplifying many things.  Capability clients are no longer thread-safe, so they don't have to be so const.  In the future, explicit ways to communicate between threads will be re-added, but threads will be treated more like separate vats that just happen to have a particularly fat pipe.  Upcoming:  Remove mutexes.

Allow implicit conversion from Orphan<T> to Orphan<DynamicStruct/DynamicList/DynamicCapability> where applicable.

Get rid of no-longer-needed object-specific methods of DynamicStruct.  Use get().as<ObjectPointer>() instead.

Revamp generated interface to Object fields.  Now there is an ObjectPointer::{Reader,Builder}.  This will simplify the dynamic API (next change) and also makes it easier to delegate decisions about the object type to a function that doesn't know about the context where the object lives (i.e. by passing an ObjectPointer::Builder).

Factor Pointer{Reader,Builder} out from {Struct,List}{Reader,Builder}.  Will make it easier to deal with Object fields.