Introspection cache

This includes the last major feature required to replace v3 - caching the introspection results to disk (see #632). This is particularly important to anyone using PostGraphile on AWS Lambda or similar environments where startup time is at a premium.

• ✨ --write-cache <path> command line option enables you to write introspection results (and anything else that the various plugins, including your own, decide to cache) to a JSON file
• ✨ --read-cache <path> command line option reads the cache back from disk allowing plugins to skip certain time-consuming tasks like introspection

You should use --write-cache during the build phase, and then --read-cache when running in production. Please note that the cache does not get invalidated, so if you edit your database schema you will need to rebuild the cache otherwise things may get... interesting.

Use of this feature is not advised unless you understand the ramifications.

---

I really appreciate the support of the 7 patrons on my Patreon ❤️ Please consider joining them: https://www.patreon.com/benjie

---

We're so close to v4 beta now I can taste it! There's just one more breaking change I want to introduce - and that's #432, an improvement to create table bar (foo_id int primary key references foo, col text)-style one-to-one relations, so that you can query fooById(id: 7) { id barByFooId { col } } rather than what is currently fooById(id: 7) { id barsByFooId { edges { nodes { col } } } } - i.e. it removes a level of indirection. I hope to add an option to allow you to disable this if you need to restore backwards compatibility, the breaking change will be the change in default behaviour.

(Sidenote: if you're using PostGraphile on AWS Lambda, please allocate at least 512MB of memory or you may risk significantly larger response times according to @jmparsons on gitter - we have not optimised PostGraphile for memory usage yet).