This includes making builders a little more tolerant of corrupt data. Note that our threat model generally does not expect this tolerance -- we expect that builders always contain either structures created locally or copied in from a reader, which does a certain amount of validation in itself.

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.

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.

The existing error message suggests this case can only arise if there is a
a bug in the library. However, malformed input can trigger the error too.
In particular, the error gets thrown when a non-double far pointer resolves
to another far pointer.

Reads and writes of volatile aligned words are automatically blessed with
atomic acquire and release semantics at compile-time by MSVC, leaving only
CPU operation reordering to worry about. x86 and x64 CPUs will not reorder
the operations, but MSVC targets Xbox, which notably will reorder them,
thus I added fences out of an abundance of caution. While Cap'n Proto
likely will not compile for Xbox as-is, I would hate for someone to port
it only to have to debug obscure atomic-operation-related crashes later.

I implemented the fences using std::atomic_thread_fence rather than
MemoryBarrier(), because including windows.h in raw-schema.h is a
non-starter, and it would be silly to reimplement it with in-line assembly
and intrinsics for every targeted CPU when <atomic> is available.

Another possible implementation could have been to use the InterlockedXxx
functions, however they present a few issues:

1. They're defined in windows.h. We could define them in terms of their
   underlying _InterlockedXxx intrinsics, but we'd need more #if blocks to
   handle both 32-bit and 64-bit pointers. If we go this route, it'd
   probably be better to go all-in and define some kj::atomic{Load,Store}
   functions.
2. We cannot implement atomic load-acquire semantics with them for const
   variables without const_casting.

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.