[FIX] Optimize JUnit processing time for large test results

[johnwonkim]

Summary

• Filter REXML's XPath result set to testcase elements with a direct failure or error child.
• Retain the existing per-testcase failure | error traversal so failure/error ordering and formatting behavior remain unchanged.
• Add regression coverage for wide suites with mostly passing testcases and record the fix under Unreleased.

Root cause

The JUnit parser currently evaluates //testcase, then inspects every matched testcase for failure or error children. REXML restores XPath matches to document order by constructing ancestor/sibling index paths, and REXML::Parent#index linearly scans siblings. For a wide suite with N sibling testcases, sorting all testcase matches therefore approaches O(N²), even when nearly every testcase passes.

The updated XPath is evaluated inside REXML:

//*[self::testcase][failure or error]

REXML still parses and traverses the complete XML document, but passing testcases do not enter its expensive final result-ordering step. The existing inner failure | error traversal is unchanged.

Selecting //failure | //error directly would not be equivalent: it could include elements outside testcases and can change REXML's union ordering.

Compatibility

The regression specs cover:

• both failure and error elements
• mixed failure/error children within one testcase
• direct-child semantics, excluding suite-level and nested errors
• nested suites and ancestor attributes used by custom summaries
• summary, message, and details output ordering
• a 2,000-testcase wide suite with deterministic bounds on REXML::Parent#index calls

Validation

• bundle exec rspec: 107 examples, 0 failures
• bundle exec rubocop: 25 files inspected, no offenses detected
• Local compatibility environment: Ruby 2.6.10 and Bundler 1.17.2 (the repository declares Ruby 2.5.1 and Bundler 1.16.2)