Inline detailed I/Y-build test results into test overview at build reports page

[HannesWell]

For the detailed test results at the build's websites a separate html page is currently generated per test-plugin.
These generated html pages are linked from the test overview table at the reports page.
For example at
https://download.eclipse.org/eclipse/downloads/drops4/R-4.39-202602260420/reports.html#tests

The html pages are generated upon completion of a test execution using the JUNIT.XSL transformation:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/fa6e87ecaaff0b9531729ee36106bf1df9e3d9d1/products/eclipse-junit-tests/src/main/scripts/JUNIT.XSL

invoked through

• eclipse.platform.releng.aggregator/production/testScripts/configuration/sdk.tests/testScripts/test.xml

  Lines 1050 to 1058 in fa6e87e

  	<xslt
  	style="${junit-stylesheet}"
  	basedir="${results}/xml"
  	destdir="${results}/html"
  	filenameparameter="filename">
  	<factory>
  	<feature name="http://www.oracle.com/xml/jaxp/properties/enableExtensionFunctions" value="true"/>
  	</factory>
  	</xslt>

• eclipse.platform.releng.aggregator/products/eclipse-junit-tests/src/main/scripts/library.xml

  Lines 162 to 164 in fa6e87e

  	<property
  	name="junit-stylesheet"
  	value="${basedir}/JUNIT.XSL" />

• eclipse.platform.releng.aggregator/production/testScripts/configuration/sdk.tests/testScripts/test.xml

  Lines 1035 to 1037 in fa6e87e

  	<property
  	name="junit-stylesheet"
  	value="${executionDir}/JUNIT.XSL" />

This approach has some drawbacks:

• the JUNIT.XSL is difficult to understand and to test and is therefore hard to maintain and has known problems, like
  • JUnit test reports don't show tests in execution order #3722
  • JUnit test reports don't preserve empty spaces #3723
• the generated static html files occupy about 240MB per build website
  • the JUnit XML files, from which the html files are generated have only half the size, but are duplicated in the testresults/xml and configuration specific folders in the testresults.

To avoid those drawbacks, my proposal is to reuse the approach already applied to the Compile issues section of a build's report page (for example at https://download.eclipse.org/eclipse/downloads/drops4/R-4.39-202602260420/reports.html#compiler-issues) and to inline the detailed build test results into the test results overview table at the build reports page.
The detailed results would then be opened as a slide down when the corresponding row or details link is clicked.
Similar to the compile issues.
The results of different configurations could be put into tabs.
The content of the test details could be stream lined in the summary table, but the very details would remain the same.
The displayed data would be all read from the files in testresults/xml.

This would save us the storage and creation of the html files and would make subsequent modifications easier to apply as one would only have to adjust the reports.html file or invoked javascript. Local testing would also be easier as described in Eclipse Build websites - Local testing.