Spellcheck the styleguide

Typo found by @mquandalle

Mentioned three days ago, didn't want it to get forgotten

Fix typo in two party RPC docs

Make sure ArrayPtr<char> stringifies the same as ArrayPtr<const char> (without commas after each character)

Use ip4 sockets for wildcard on OpenBSD

Short-term fix for #220.

Fix typos.

Added method accept() to TwoPartyServer for servicing arbitrary AsyncIoStreams.

Increase arenaSpace to fix 32-bit builds.

Fix bug in JSON encoder that caused each byte of a UTF-8 sequence to be escaped as a separate character.

Added capnp::TwoPartyServer::accept(...) this method allows capnp::TwoPartyServer to service arbitrary kj::AsyncIOStream objects such as those representing two-way pipes (socketpairs).

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

Fix bug dereferencing nullptr when forwarding a large skip

Make tests work on mipsel, maybe. Hopefully fixes #204. I don't know since I don't have a mipsel machine.

Example:

    const data :Data = embed "some-file.dat";

Files are looked up the same way an import would be.

You can use embed when Data or Text is expected. You can also use it when a struct type is expected -- the file will be interpreted as a message using standard binary serialization.

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.

Update RPC docs for the change to a single bootstrap interface