`MultisetExpression` rework, again

[HighDiceRoller]

Basically the idea is that expressions outside of multiset_function would attach to generators, and expressions inside would attach to evaluators. This is mostly driven by cache reusability.

Here the "cut point" for unbinding would be at the first non-fully-bound expression node, rather than immediately at the generator.

[HighDiceRoller]

This could turn into a more comprehensive rework of MultisetExpression. Issues to look at:

• A lot of the overhead is due to the cost of function calls. I don't think it's conscionable to do opcodes and a giant if-else, but perhaps we can keep it to one function call per node. This may also call for inlining some of the current operators.
• Somewhat against this, currently the expression nodes themselves are responsible for propagating next_state etc. to the subexpressions, which makes writing new expression types kind of annoying. Possible alternatives include:
  • We could have next_state call an abstract function that only handles the current node and implement the subexpression handling in the base class. Though this would introduce an extra function call per node.
  • We could put more of the intelligence in the evaluator, though I'm not sure this would work well on the generator side.
• We may need to make next_state only consider local information anyways, because the generation and the evaluation will probably use it in different ways. The generator needs to produce a cacheable unit, which is currently an instance itself, and probably should remain so. On the other hand, the evaluator side uses an separate state object rather than an instance itself.