Ensure alpha conversion always runs when a new variable is bound

[eb8680]

This PR fixes a longstanding alpha-conversion edge case by guaranteeing that newly bound variables are always alpha-renamed, which is currently not the case due to the way alpha-conversion interacts with cons-hashing. For context, this issue turned out to be the root cause of some strange, difficult-to-debug errors that came up when I tested funsor.adjoint with funsor.sum_product.modified_partial_sum_product. I imagine @ordabayevy will run into this at some point, so think of this PR as preemptive unblocking.

Recall that alpha conversion in Funsor is implemented with name-mangling of subexpressions in reflect: whenever a variable is newly bound in a Funsor expression, we append to its name a unique suffix of the form f"__BOUND_{identifier}".

However, to ensure that expressions that bind variables are cons-hashed, we have to avoid mangling names twice. This is currently achieved by only mangling bound variables whose names do not already contain a __BOUND_ suffix, a heuristic that can sometimes break down when subexpressions containing mangled inputs are temporarily exposed for further processing. This PR switches to always mangling bound variables and should guarantee that alpha-conversion always behaves as expected.

Tested:

• Added a simple regression test that fails on master
• Exercised explicitly by existing tests in test_alpha_conversion.py and implicitly in any test that compares identities of expressions with bound variables (x1 is x2)

[eb8680]

This line ensures that _alpha_mangle does not break cons-hashing.

[eb8680]

The CI failures are RecursionErrors in examples/hmm.py. After some investigation it seems like there's an odd interaction happening between substitute and funsor.optimize.apply_optimizer that's causing the stack of interpreters to blow up. I don't think it's related to the changes in this PR; they just happened to make it more obvious. I'll have to fix that first before this can be merged.

[eb8680]

there's an odd interaction happening between substitute and funsor.optimize.apply_optimizer that's causing the stack of interpreters to blow up

Update: I believe I have fixed this by forcing alpha-renaming substitution to run under reflect, which I believe is always correct. The same example is still giving a RecursionError, but I think the root cause has changed. Still investigating...

[eb8680]

This recent paper seems quite relevant, although it solves a slightly different problem.