Add cached interpretations and use for typeof

[jfeser]

Adds a notion of a cached interpretation (these interpretations handle the internal operation _is_memoized). When evaluating a term under a cached interpretation, we set a cache attribute on the term that we can reuse for later evaluations under the same interpretation.

Blocked by #713 (only for the benchmark)

Before:

---------------------------------------------------- benchmark: 1 tests ----------------------------------------------------
Name (time in ms)                    Min       Max     Mean   StdDev   Median     IQR  Outliers      OPS  Rounds  Iterations
----------------------------------------------------------------------------------------------------------------------------
test_bench_term_construction     60.1234  127.2249  65.1138  16.5825  60.9053  0.8398       1;2  15.3577      16           1
----------------------------------------------------------------------------------------------------------------------------

After:

-------------------------------------------------- benchmark: 1 tests -------------------------------------------------
Name (time in ms)                   Min     Max    Mean  StdDev  Median     IQR  Outliers       OPS  Rounds  Iterations
-----------------------------------------------------------------------------------------------------------------------
test_bench_term_construction     4.1599  5.0849  4.4263  0.1847  4.3989  0.2841      35;1  225.9233     111           1
-----------------------------------------------------------------------------------------------------------------------

Open design questions:

• The cache needs to distinguish non-equivalent interpretations. It does this with object identity. We could use a stronger comparison operation and get more cache hits. For example, coproduct({}, i) != i in the current implementation.
• Whether an interpretation is cached is determined by whether it handles an operation. This means that coproducts with this interpretation will also be cached. Do we want cachability to inherit in this way?

Previous attempt: #252

[jfeser]

#594 is related; it adds a cache that persists for a single evaluate call. This approach is orthogonal. This PR does not improve the evaluation of terms with sharing, and #594 does not reduce the complexity of defdata.

[eb8680]

Looks like a nice improvement, I just have a couple of small comments.

Also, what happened to removing internals.product_n?

[eb8680]

Would it be cleaner to define this as a functools.cached_property of Term?

[jfeser]

This version avoids the need to update implementers of Term, but a cached property is cleaner.

[jfeser]

I think since we have a variety of internal and external implementers of Term, some of which don't subclass it, we should stick with the current implementation.

[jfeser]

I found new uses for product_n in #719.

[eb8680]

I wonder if this should be more conservative and use object identity instead of a semantic hash of self.implementations?

[jfeser]

I think the semantic hash is correct and slightly more precise, but it doesn't make much difference in our use.