test: fix SupportBean capture assertions regardless of capture order

[lawrencewang49]

Summary

This PR fixes a flaky test in the regression suite that failed nondeterministically under NonDex runs. The test previously assumed a fixed ordering of captured SupportBean instances, which caused failures when the internal order varied.

Changes Made

• Updated assertions to check for the presence of SupportBean objects with specific intPrimitive values (10 and 11) rather than assuming they appear in a specific order within DefaultSupportCaptureOpStatic.getInstances() as shown below:

SupportBean captured1 = (SupportBean) DefaultSupportCaptureOpStatic.getInstances().get(0).getCurrent().get(0);
SupportBean captured2 = (SupportBean) DefaultSupportCaptureOpStatic.getInstances().get(1).getCurrent().get(0);
boolean found10 = captured1.getIntPrimitive() == 10 || captured2.getIntPrimitive() == 10;
boolean found11 = captured1.getIntPrimitive() == 11 || captured2.getIntPrimitive() == 11;
assertEquals("Expected to find bean with intPrimitive=10", true, found10);
assertEquals("Expected to find bean with intPrimitive=11", true, found11);

• Ensured test reliability across different JVM iteration orders and NonDex configurations.

Reasoning

NonDex revealed that the original test relied on non-deterministic ordering of internal data structures. By verifying the existence of expected values instead of positional order, the test now correctly validates functionality without being sensitive to iteration sequence.

Testing

• Verified that the test passes consistently under multiple NonDex runs.
• Confirmed no behavioral changes to the production code, this is a test-only fix.

Impact

• Improves test suite stability and reproducibility.
• Reduces false negatives caused by order-dependent assertions.

Steps to Reproduce

1. Run mvn install -pl regression-run -am -DskipTests
2. Run mvn -fn -pl regression-run edu.illinois:nondex-maven-plugin:2.1.7:nondex -Dtest=com.espertech.esper.regressionrun.suite.epl.TestSuiteEPLDataflow -DnondexRuns=10, which should output the following:

Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.632 sec <<< FAILURE!
testEPLDataflowOpFilter(com.espertech.esper.regressionrun.suite.epl.TestSuiteEPLDataflow)  Time elapsed: 1.617 sec  <<< FAILURE!
java.lang.AssertionError: expected:<10> but was:<11>
	at org.junit.Assert.fail(Assert.java:88)
	at org.junit.Assert.failNotEquals(Assert.java:743)
	at org.junit.Assert.assertEquals(Assert.java:118)
	at org.junit.Assert.assertEquals(Assert.java:555)
	at org.junit.Assert.assertEquals(Assert.java:542)
	at com.espertech.esper.regressionlib.suite.epl.dataflow.EPLDataflowOpFilter$EPLDataflowAllTypes.run(EPLDataflowOpFilter.java:110)
	at com.espertech.esper.regressionrun.runner.RegressionRunner.run(RegressionRunner.java:77)
	at com.espertech.esper.regressionrun.runner.RegressionRunner.run(RegressionRunner.java:53)
	at com.espertech.esper.regressionrun.suite.epl.TestSuiteEPLDataflow.testEPLDataflowOpFilter(TestSuiteEPLDataflow.java:58)