Minor test fixups
Simpler tree values and sets
Remove last vestiges of an ugly hack around lack of typeclasses
A bit of refactoring in preparation for major store-passing change
Change store-passing arrows to send substores to subcomputations

This is the first major departure from the semantics in the dissertation.

In the semantics, probabilistic stores are a pair of a tree-shaped
infinite vector of random numbers, and a tree-shaped infinite vector
of imposed branch decisions. They're passed as-is from one computation
(roughly, expression) to its subcomputations (roughly, subexpressions).
Each computation is assigned an index into the store. The computations
for `random` and `if` expressions ref the store using their index to
determine which number to return and which branch to take, respectively.
Theoretically, this is nice and simple.

Practically, it's bad for performance. It makes `random` and `if` take
time proportional to their runtime depth, which bounds finite programs'
runtimes by O(n*n) in the number of expressions in the worst case.
It also makes memoizing difficult. Naively, a change to *any* part of
the store invalidates all caches. Non-naive change detection would
probably take too much time to compute.

The major departure is this: computations now split the store in half
and send each half to their subcomputations. Now `random` and `if` are
constant-time (they just peek at the top of one of the trees in the
store), and a change to the store directly affects only the results of
the computations assigned to the nodes in the path from the changed
node to the root.

There are three negative effects.

1. It's a little more difficult to keep the preimage* arrow in sync
with the indexes arrow. Previously, they both passed the same new tree
index to subcomputations. Now the preimage* arrow operates on the
store and the indexes arrow operates on indexes into the store.

2. The preimage* arrow combinator definitions are more complicated.
This makes them harder to reason about and increases running time by
a constant factor.

3. Somehow, this has resulted in O(n*n*log(n)) performance, according
to tests; it used to be O(n*n).

I'm not sure where #3 came from. Hopefully memoization will take care
of it.