Avoid a set per combineWith and cache TransitionFunctionImpl's hash

[swissiety]

Follow-up to #281, picking up the allocation concern from its review.

What changes

• combineWith built a LinkedHashSet of both functions' state change statements on every call, only to discard it in the common case where the union is a single statement. It now checks whether the other function already has all of this function's statements (typically both have the same single one) and, if so, returns a function of the other's kind with the merged sequences. Only a genuinely new combination builds an ImmutableSet, which CombinedTransitionFunctionImpl takes over without copying (ImmutableSet.copyOf on an ImmutableSet is a no-op).
• hashCode() hashed the whole sequence multimap on every call, while weights are hashed repeatedly as keys of the automata's maps. The functions are immutable, so the hash is computed once and cached (the same racy-single-check idiom as String.hashCode). With compressed oops the extra int fits in the existing padding of a plain TransitionFunctionImpl; only the rare combined instance grows by 8 bytes.

Behaviour is unchanged: the result has the same set of state change statements as before, getStateChangeStatement() returns the same statement, and combining stays commutative and idempotent. TransitionFunctionImplTest gains an assertion for the shortcut direction and for hash equality of the commutative results.

Testing (-DtestSetup=Soot)

• All idealPDS test classes pass except IteratorHasNextTest test1/test2/test4, which fail identically on develop.
• FileMustBeClosedTest (49 tests): 71.1 s on this branch vs 73.7 s on develop, one run each, so within noise. No regression, but no claimed speed-up either.

🤖 Generated with Claude Code