`evaluate` should call constructor operations when rebuilding collections

[jfeser]

This is a proposal to make evaluation of terms that contain collections more uniform and easier to control using handlers.

We should modify evaluate so that it calls a construction operation when evaluating through a collection. This would simplify the implementation of any interpretation that provides a non-standard evaluation that doesn't preserve collection structure.

For example, evaluate([a(), {0: (b(), c()}]) should call as_tuple, as_dict, and as_list (effectful wrappers of the stdlib collection constructors) when rebuilding the respective collections. An analysis that returns the set of nullary operations in a term could then be written as:

class Vars(ObjectInterpretation):
    @implements(apply)
    def _(op, *args, **kwargs):
        return {op} if not args and not kwargs else set().union(*args, *kwargs.values())

Currently, analyses like this need to implement their own collection flattening or use mutable state (see fvsof, sizesof).

We can retain the existing term representation that allows embedded collections, but this change would make terms truly equivalent to trees of operations applied to values.

#641 is an ad-hoc version of this change that only treats dataclass constructors.

[jfeser]

We might also be able to capture most of what nested_type currently does using the type annotations on the collection constructors.

[eb8680]

#680 is also an instance of this, I think