Memoize expensive ns data transformations in a dynamic var

Namespaces often contain more than one import/alias/refer. In these
cases the repeated data transformations of (all-ns) in a single ns
reconstruction is wasteful. Properly memoizing these calculations
results in a considerable performance gain for namespaces with many
references.

A dynamic var is a suitable place for a cache:

    - The current compiler-failure algorithm forces us to work
      sequentially, so a thread binding is not a problem

    - Reconstruction _should_ work with and without a cache for testing

A parallel reconstruction algorithm will require explicit
parameterization of the cache, but we can cross that bridge when we get
there.

The *cache* var is not bound in slam.hound.regrow; that is up to the
discretion of consuming code (tests and the main entry points in
slam.hound). The with-regrow-cache macro can be nested, in which case
the topmost cache is used.

The performance benefit of this change depends on the namespace:

    - Namespaces with a single import/alias/refer are unaffected¹

    - Small namespaces with multiple references of each type experience
      relatively large gains (40% - 50% reduction of reconstruction time)

    - Large namespaces with multiple references experience the same
      absolute speedup as above, but since the time required for
      evaluation of the namespace now dominates, the relative reduction
      in reconstruction time is less dramatic (10% - 30%)

It is unclear whether the size and use of this cache has negative
effects on GC, so this branch is considered experimental. Intuitively,
the reduction of object creation should help reduce GC hiccups, but
tests should be done in larger projects.

The overall effect of this change is that ns evaluation in
check-for-failure is now the largest performance bottleneck by two
orders of magnitude.

¹ Actually, commit d80d4a3 removed the inner loop in :refer candidate
  generation, but the new symbols->ns-syms re-adds one. The inner loops
  of both iterate through the public vars of each ns, so running time is
  only increased linearly by the average count of public vars per ns *
  ns, not geometrically by the number of namespaces.
Execute reconstruct and -main with-regrow-cache

The two main entry points for Slamhound are slam.hound/reconstruct and
slam.hound/-main. Binding slam.hound.regrow/*cache* in both places
allows speed up of both single-file reconstruction (via an editor),
as well as an even greater speed-up of recursive reconstruction of a
directory.

One issue that may arise is that all data about namespaces is cached
on first calculation, so any namespaces or classes created as a result
of a newly evaluated namespace will not be visible in subsequent
reconstructions while reconstructing all clojure files in a directory.

It's unclear how utilizing this assumption about the behavior of
recursive reconstruction could be regarded as anything but a bug, so I
am unconcerned.
Merge branch 'regrow-cache'

After a month of use, I have not noticed any problems with these
changes.

* regrow-cache:
  Execute reconstruct and -main with-regrow-cache
  Memoize expensive ns data transformations in a dynamic var
Handle case where an alias is used to refer to private vars

e.g.
    (ns alpha)

    (def ^:private foo)
    (def bar)

    (ns beta)

    (def foo #'a/foo)
    (def bar a/bar)

The beta namespace uses the `a` alias to refer to both alpha/bar and the
private var alpha/foo.

Slamhound previously failed to find `alpha` -> `a` in this case since it
attempts to find a ns that contains #{foo bar} in its set of _public_
vars.

The solution implemented here is to try the alias search twice, once
with all symbols, and again without (var symbol) forms.

This does mean that Slamhound will be unable to find aliases that are
used to refer to both public and private vars via #':

    (def foo #'b/private-var)
    (def foo #'a/public-var)    ; Just use a/public-var