terml rewrite

This reworks the branch to use terml, and to have a two-stage separation between parser and interpreting, and between mapping Python to edn ('decoding') and unparsing.

## notes for reviewer

1. `_extended._Decoder` and `_ast._Builder` have roughly the same shape and
   similar problems (`leafData` is weird, shouldn't even need to handle
   `'.tuple.'`, dispatch is inevitably on `tag.name`, `term` method is almost
   guaranteed useless).  Muck around a bit with making a better direct API for
   term traversal in terml.
2. Maybe leave `decode` policy-free, passing in `_DECODERS` and
   `DEFAULT_READERS` and leave the default policy shenanigans up to `loads`
3. In a later branch, I want to refactor `encode` to have a separate, generic
   Python object traversal thing.  I need to sit down and think about this one.
4. Perhaps create an `unknown_handler` for `encode`, and also base rules for
   encoding supported types like int, float, and so forth.
5. Doesn't support numbers as well as it could.  I think this can wait for a
   later branch.
6. Almost 100% of the extension is going to be turning a domain-specific object
   into a tagged value and back.  We need to make sure there's a good API for
   that.
7. `constantly` belongs in perfidy
8. Default encoding rules map tuples to lists and lists to vectors, basically
   because tuples use parens and lists use brackets.

## questions for reviewer

1. How do you feel about the module break up?
2. Can you come up with better names than `encode` and `decode`?
3. Should there be exposed `Keyword` and `Symbol` objects that are *not*
   terms, but rather representing actual keywords and symbols?  Would make
   some things (e.g. type-based dispatch in `encode`) easier.
   * Maybe give `Symbol` a `makeTag` method, so that `INST.makeTag("2013-...")` works?
4. What should `encode` do with `TaggedValue`s?
5. I haven't really thought much about the public interface. Is anything public that should be private? Private that should be public?