Separate tests and benchmarks
Benchmarks for deep term unification

These benchmarks measure how quickly Golog can unify two compound terms when
their structure is deeply nested.  In the first benchmark, unification
succeeds.  In the second, it fails.  Initial results:

    UnifyDeep        500000              7445 ns/op
    UnifyDeepFail   2000000               909 ns/op
More low-level benchmarks
Unification hashing infrastructure

This will form the basis of clause indexing.  It might eventually be
used to optimize normal unification, but initial benchmarks show that
it doesn't help.
Fix typo in database tests

The clause asserted in the database is foo(one,two) and foo(a,b)
doesn't unify with that.  The old test only worked as long as the
database did no indexing at all.
Remove dead code related to atoms

Atoms used to be represented as Compound terms with 0 arity.  Now that
there's a dedicated atom type, there's no need for this check.
Comment out low-level benchmarks

I don't usually want to run these benchmarks.  They're mostly useful
during specific optimization attempts.
Extra indirection for unification hashes

Each compound term stores two unification hashes to help optimize
unification.  I've moved the cache to a separate object which multiple
compound terms can share.  By intelligently sharing these caches, we
can avoid re-hashing large compound terms.  That should save a fair
amount of computation.
Preserve unification hashes across variable renaming

Renaming variables in a compound term doesn't change the term's
unification hash.  Because hashes are somewhat expensive to calculate,
it should benefit us to preserve the cache.

If hashes haven't been calculated for the original term yet, they'll
be updated as soon as either term calculates the hashes.
Implement clause indexing

Clause indexing is implemented in terms of unification hashing.
Before considering a clause as a candidate, its unification hash must
indicate that the two terms might unify.

This appears to work exactly as intended and reduces the number of choicepoints
generated during typical queries.  It also reduces unwanted nondeterminism in
queries.

Surprisingly, this has almost no impact on performance benchmarks.  I expected
it to cut run times in half for BenchmarkAppend and BenchmarkNaiveReverse.

    True               10139 ns/op
    Append            297719 ns/op
    UnifyDeep           7523 ns/op
    UnifyDeepFail        959 ns/op
    UnificationHash     9776 ns/op
    Maplist           923803 ns/op
    NaiveReverse   117587650 ns/op
    Read              109328 ns/op

I'll need to poke around in some profiling data to see what's holding up the
show.

Closes #7