This implements JSON-RPC 2.0: https://www.jsonrpc.org/specification

This avoids the need for a weird struct-as-namespace pattern inside json.capnp.

Features:
- Rename any field or enum value for JSON purposes.
- Flatten structs/groups into their parent object, possibly with a prefix.
- Assign a special discriminant field for unions, so that union members can be flattened without ambiguity.

Simplifiy implementation and, as a bonus, allow overflowing floating numbers to convert to +/-Infinity like they do in JSON.parse.

Also update outdated comment about NaN and Infinity being encoded as `null`.

 - Add support for decoding with Orphanage.
 - Allow decoding of non-struct root JSON objects.
 - Add support for custom decoding type handlers.
 - Add support for custom decoding field handlers.

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

This conversion would end up including the NUL terminator in the array, which is almost never what you want.

We can perhaps re-enable this in the future and have it automatically remove the NUL terminator, but we should do at least one release with it disabled to catch anyone who might be affected by the change in behavior.

Fix JSON handler for DynamicStruct. The handler needs to be told the struct's schema to construct an orphan.

Also improve error message when addTypeHandler() is given a handler for a dynamic type but no specific schema is specified. We could support this eventually but we don't presently.

Problem discovered and initial test case contributed by Harris Hancock.

Such values are not allowed by the JSON spec. We match the behavior of
JSON.stringify in Firefox and Chrome.

fixes https://github.com/sandstorm-io/capnproto/issues/261

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