You can now spawn a canonical message from:
* StructReader
* AnyStruct::Reader
* capnpc-c++ generated Foo::Reader

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.

Initially I meant to ensure the allocator gave back sequential memory in
segment0, but ended up using a hope+validate approach. Given this
approach, modification of this function adds useless complexity.

Previously I assumed that data sections in the input StructReader must
have data sections which were multiples of words. However, struct
upgrade rules allow a StructReader to exist which does not follow that
rule. This commit removes that assumption by working in bytes normally,
and special casing the 1-bit-struct case.

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.

As of that change, adopting an empty struct into a pointer that already had some other value fails to overwrite the upper 32 bits of the pointer, thus resulting in a struct pointer with totally bogus bounds. Normally this will either cause a bounds check exception to be thrown when that pointer is later accessed, or lead to a struct containing bogus data (but if teh struct was expected to be empty, probably that data is never accessed).

Add a way to concatenate lists without losing data when one or more of the lists was written using a newer version of the protocol.

Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an object that does not point back to the sender."

The problem happened when pipelined calls were made on a promised capability, but then that capability turned out to be null. The promise resolving code incorrectly interpreted this as the remote promise having resolved to a local capability (because the "null" stub capability looks local), and so it would send a Disembargo message to flush the pipeline as required. However, the remote end would receive this Disembargo message and find it is addressed to a null capability, not a capability pointing back to the sender. This was treated as a protocol error, causing the receiver to close the connection.

The solution is to explicitly identity "null" capabilities so that we can distinguish this case. This change also has the benefit that now when you copy a null capability between messages with foo.setCap(bar.getCap()), the pointer will be set null in the destination, rather than becoming a reference to a local broken capability.

Thanks to David Renshaw for narrowing this down.

Also introduce a way to copy a struct or list which applies membranes to all embedded capabilities, since this seems like it will be needed in conjuction with the above.

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

Fix bug where capability pointers were corrupted when 'transferred', e.g. using adoptWithCaveats() or truncate().

Unfortunately, commit 10487060 missed a case of CPU amplification via struct lists with zero-sized elements.

See advisory: https://github.com/sandstorm-io/capnproto/blob/master/security-advisories/2015-03-05-0-c++-addl-cpu-amplification.md

Deep-clear target object when overwriting pointer. (Minor bug I noticed while working on other things.)

Details: https://github.com/sandstorm-io/capnproto/tree/master/security-advisories/2014-03-02-0-all-cpu-amplification.md

Details: https://github.com/sandstorm-io/capnproto/tree/master/security-advisories/2014-03-02-1-c++-integer-underflow.md

Details: https://github.com/sandstorm-io/capnproto/tree/master/security-advisories/2014-03-02-0-c++-integer-overflow.md

The project file still only compiles a test binary, but it should be easy to separate out a library project from here.

Thanks again to Bryan Boreham <bjboreham@gmail.com> for much help getting this working.