Fix StackOverflowError due to non-commuting TransitionFunctionImpl.combineWith

[marcus-h]

    Fix StackOverflowError due to non-commuting TransitionFunctionImpl.combineWith
    
    According to the theory, the combineWith operation of the
    TransitionFunctionImpl class has to be, among other things, commuative. This
    can result in a StackOverflowError (see
    VectorTest.testNoStackOverflowDueToNonCommutativeCombineWith for a reproducer).
    Excerpt from the stack trace:
    
            ...
            at wpds.impl.PostStar.update(PostStar.java:335)
            at wpds.impl.PostStar$HandleNormalListener.onOutTransitionAdded(PostStar.java:227)
            at wpds.impl.WeightedPAutomaton.addWeightForTransition(WeightedPAutomaton.java:329)
            at sync.pds.solver.SyncPDSSolver$4.addWeightForTransition(SyncPDSSolver.java:194)
            at wpds.impl.PostStar.update(PostStar.java:335)
            at wpds.impl.PostStar$HandleNormalListener.onOutTransitionAdded(PostStar.java:227)
            at wpds.impl.WeightedPAutomaton.addWeightForTransition(WeightedPAutomaton.java:329)
            at sync.pds.solver.SyncPDSSolver$4.addWeightForTransition(SyncPDSSolver.java:194)
            at wpds.impl.PostStar.update(PostStar.java:335)
            at wpds.impl.PostStar$HandleNormalListener.onOutTransitionAdded(PostStar.java:227)
            at wpds.impl.WeightedPAutomaton.addWeightForTransition(WeightedPAutomaton.java:329)
            at sync.pds.solver.SyncPDSSolver$4.addWeightForTransition(SyncPDSSolver.java:194)
            at wpds.impl.PostStar.update(PostStar.java:335)
            at wpds.impl.PostStar$HandleNormalListener.onOutTransitionAdded(PostStar.java:227)
            at wpds.impl.WeightedPAutomaton.addWeightForTransition(WeightedPAutomaton.java:329)
            at sync.pds.solver.SyncPDSSolver$4.addWeightForTransition(SyncPDSSolver.java:194)
            at wpds.impl.PostStar.update(PostStar.java:335)
            ...
    
    When combining the two paths in doSth, a new TransitionFunctionImpl is created
    where the statement sequences are merged but the stateChangeStatement from one
    of the path is used. The latter causes the
    PostStar.update <-> WeightedPAutomaton.addWeightForTransition "ping-pong".
    In order to fix this, store stateChangeStatement(s) from both paths in a set.
    
    Implementation note: a LinkedHashSet is used so the getStateChangeStatement()
    can be easily implemented (whether the method itself is "meaningful" is
    debatable, though).

[swissiety]

👍

[swissiety]

as this is the only ctor using/storing multiple elements it seems to make sense to create a seperate specialized class for it and keep storing the single element here.

[marcus-h]

Hmm what's the benefit of a separate class? The single element case is handled in the ctor above. I could also make this ctor private (if you're worried about the class' API - it would make overriding the combineWith method a bit more cumbersome, though).

[swissiety]

less memory / no linked list overhead - in the cases where we don't need it. I haven't benchmarked it but it seems like a core element that can be generated quite some times.