Utility belt for Clojure in the wild

Core utilities for parsing our 'fnk'-style binding syntax.
Documented and tested through the actual 'letk','fnk', and 'defnk'
macros in plumbing.core.

The core entry points into this namespace are 'letk*' and 'fnk*',
which parse the new binding syntax and generate fnk bodies,
respectively.

For efficiency, two different methods of generating fnk bodies are
used.  If the fnk takes a fixed set of arguments (i.e., no & or
:as), then a 'positional' version of the fnk that is called like an
ordinary Clojure fn (e.g., (f a b) rather than (f {:a a :b b}) is
generated as an implementation detail, and stored in metadata of
the actual keyword fnk (which is just a thin wrapper around the
positional version).  If '& or :as are used, no such positional
function is generated.

The advantage of these 'positional' functions is that they can be
accessed using 'efficient-call-forms' or 'positional-fn' to call
the fnk without incurring the overhead of producing and then
destructuring a top-level map.  See plumbing.graph.positional for
an example use.

Core protocol and helpers for schema.core to extract and attach
input and output schemas to fnks. This protocol says nothing about
how fnks are created, so users are free to create PFnks directly
using fn->fnk, or using custom binding syntax (of which 'fnk' et al
are one possible example).

A very simple type system for a subset of schemas consisting of nested
maps with optional or required keyword keys; used by fnk and kin.

Since schemas are turing-complete and not really designed for type inference,
(and for simplicity) we err on the side of completeness (allowing all legal programs)
at the cost of soundness.

These operations also bake in some logic specific to reasoning about Graphs,
namely that all input keys to a node must be explicitly mentioned as optional or
required, or provided via `instance`, and will thus deliberately drop extra key
schemas on inputs as appropriate.  Output schemas may not have optional keys.

A Graph is a simple, declarative way to define a composition of functions that is
easy to define, modify, execute, test, and monitor.

This blog post provides a high-level overview of Graph and its benefits:
http://plumatic.github.io/prismatics-graph-at-strange-loop

Concretely, a Graph specification is just a Clojure (nested) map with keyword keys
and keyword functions at the leaves.

A Graph is defined recursively as either:
  1. a keyword function (i.e., fn satisfying PFnk), or
  2. a Clojure map from keywords to (sub)graphs.

A Graph is a declarative specification of a single keyword function that
produces a map output, where each value in the output is produced by executing
the corresponding keyword function in the Graph.  The inputs to the keyword
function are given by the outputs of other nodes in the graph with matching
keywords (mimicking lexical scope in the case of nested maps), or failing that,
from keywords in the input map.

For more details and examples of Graphs, see test/plumbing/graph_examples_test.cljx.

A compilation method for graphs that avoids maps for speed.
Prone to failure for graphs with more nodes than `max-graph-size`.

Common operations on maps (both Clojure immutable and mutable Java stuff)