Note that embedded schema structures in generated code are still incorrect.

That is to say, whereas previously we would extend capnp::typeId<T>() to a new type by declaring a specialization of it for that type, now we instead have the type contain a nested class called _capnpPrivate which contains a `typeId` constant.

This is necessary because it is impossible to specialize a template for a type which is itself nested inside a template type. E.g. it's impossible to write a specialization `template <typename T> typeId<Foo<T>::Bar>()`; C++ simply doesn't support this. But with generics, Cap'n Proto will allow types to be nested inside templates, so we need this to work.

1) Apparently mixing member defaults and initializer lists is a C++14 thing.
2) My test script compiles with -Werror which errors out on calls to now-deprecated getDependency().

More refactoring is needed, but this at least makes "using" aliases work correctly with generics.

add fix for older cmake versions

Add initial cmake build support

* Move binaries into the bin directory and libs into the lib directory in the output
* Make sure the actual binary output file of capnp-tool is just capnp
* Remove need for deprecated cmake get_property function

Add ReaderOptions configurability to EzRpc

Fix typo in grammar.capnp.

Add a defaulted ReaderOptions argument to the constructors for
EzRpcServer and EzRpcClient to allow large/deep message uses more
easily.

Actually, let's use single digits for these otherwise they'll actually be printed in scientific notation with a '.', defeating the purpose of the test.

Appending 'f' to an integer literal doesn't make it a float. We have to add '.0' first.

Fixes #119.

This only happened if the Finish message indicating cancellation and the Return message happened to cross paths. If the Finish arrived before the Return was sent, then the server would send an empty response. If the Return was received before the Finish was sent, the client would properly record caps in the response. But if they crossed paths, the server would send back a full response with caps, but the client would never bother to inspect that response, thus leaking the caps. Fix is to set the flag to release all returned caps in the Finish message when cancelling.

Fix obscure bug where the last outgoing message (and any capabilities therein) would not get released (until a new message was sent, replacing it as the last).

This took hours to track down, because it initially looked like "Release" messages weren't being honored in some cases (when they happened to be releasing a capability from the last message, and no subsequent messages were sent). Initial attempts to capture this in a unit test failed because the test of course used a subsequent call to detect if the capability had been released, which succeeded.

Fix link to 'Capability Myths Demolished' paper

The old link isn't currently working.

Fix typo

Replace AC_PROG_LIBTOOL with LT_INIT in configure.ac

AC_PROG_LIBTOOL is a deprecated name for older versions of LT_INIT.[1]

1. http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html