fixes #304

In Sandstorm, we are encoding powerbox queries in packed base64 strings which may be placed in URL query parameters or the like. The strings are provided in interfaces called browser-side. We anticipate that some developers will prefer to specify a hardcoded string rather than generate it on-the-fly, since Cap'n Proto is not well-supported in browsers today, and anyway the developer may have no other reason to have a Cap'n Proto dependency at all, and powerbox queries are often static.

In this context, speed is irrelevant, while having a compact encoding is desirable. It felt sad to me to leave in the segment table in this context, adding redundant bytes when we want a compact encoding.

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

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.

Unfortunately, the layout algorithm had a bug which caused incorrect layout when declaring a union whose lowest-ordinal field was of type Void and nested in an inner union. That is:

    union {
      a :union {
        b @0 :Void
        ...
      }
      ...
    }

In this case, all the fields in the struct after the Void field -- including both unions' discriminants -- would end up misplaced. Although they did not end up overlapping (and therefore the incorrect layout "worked"), the result broke schema evolution rules around "retroactive unionization".

Unfortunately, we must break compatibility with any protocol that happened to contain the above pattern. Luckily, it's a fairly obscure case. Unluckily, Cap'n Proto's own schema format contains such a pattern. Luckily, the use of this pattern was introduced in v0.6.x and therefore has not been in any release build so far.

And add a test to verify this behavior.

Add thisCap() method to capability servers which returns a capability to itself. Remove CapabilityServerSet's weak pointers since this supersedes them.

Fix but where interface server's transitive superclass's methods weren't dispatched correctly -- ouch.

Add asGeneric() methods to generic readers, builders, and interfaces which casts them to the same type but with different generic parameters.

A compatibility layer is provided to ease migration.

Distinguishing between "local bugs" and "preconditions" was proving difficult in practice, because a precondition failure in one function may very well indicate a bug in a calling function, but the exception may be thrown through that function, thus when caught the classification is nonsensical. The distinction also was not as useful as imagined. So, I eliminated this distinction.

Add asBytes() and asChars() methods to array classes to reinterpret-cast to bytes / chars, since this happens all the time and is otherwise a huge pain.

Use the new methods in a bunch of places.

This prevents the compiler from reporting warnings in these headers while compiling application code. Hopefully this will stem the never-ending stream of complaints from people who enable pedantic warnings.