This encapsulates the input array, hiding it from the parser's methods.
Access is forced to go through `advance` and `consume*` methods on the
new `Input` object. The aim is to make it harder to have errors like
https://github.com/sandstorm-io/capnproto/pull/270

This reduces dependencies on stdc++. For rationale, see
  https://github.com/kamalmarhubi/capnproto/commit/62a562f6d2c7bd147958106a1cf4169533d43f83#commitcomment-14375773

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

Per spec.

This includes:
- ensuring we don't go off the end of input if it's not null-terminated
- checking for overflow and underflow
- being more careful to check that numbers match JSON lexical syntax

This is the first step towards JSON decoding, implementing the basic
functionality of JsonCodec::decodeRaw. The main outstanding issues are:

- it allows trailing commas in arrays and objects
- it is too liberal in number syntax, eg allowing a leading +
- it does rejects non-ASCII characters in \u escapes

Refs https://github.com/sandstorm-io/capnproto/issues/255

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

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