`.capnp` files in a subtree

[rustaceanrob]

After revisiting #174, a client can take the capnp files from bitcoin/src/ipc/capnp with essentially no changes and use them to generate client code in their target language. Would it make sense to add these to a separate repository and tag them per each release in Bitcoin Core? i.e. if I would like to build on v0.30 IPC interface, I would clone the capnp file repository and checkout the v0.30 tag.

Perhaps related to #54, maybe these tags are not dependent on Bitcoin Core and reflect the semantic versioning of the capnp schema.

[Sjors]

It's likely that the interface will be stable throughout each major Bitcoin Core version, e.g. v30.x.

Apparently it's not possible to clone just a subdirectory and the Bitcoin Core repo is huge, so maybe a subtree does make sense.

However it would add quite a bit of overhead on the Bitcoin Core side to make changes.

[TheCharlatan]

I still think they should just be installed by Bitcoin Core in something like include/capnp.

[ryanofsky]

Yes I think a good solution to this is to install the files and maybe include them in binary releases.

Cap'n Proto and and libmultiprocess (when build standalone) do already install files like /capnp/c++.capnp and /mp/proxy.capnp, and there's no reason bitcoin can't do the same with it's own files.

The git cloning situation is awkward, but moving the files to a different repository could create a lot of problems, because the src/ipc/capnp/ files need to be kept in sync with the src/interface/ files otherwise the build breaks, so it is nice to be able to update both atomically.

[ryanofsky]

Maybe github can support features like https://josh-project.github.io/josh/intro.html to make partial cloning easier someday too