Add capability to log CQL evaluation results during Measure integration testing to help debug

[lukedegruchy]

Summary

This MR adds debugging support to the Measure/MultiMeasure integration testing framework by making CQL evaluation results available for logging alongside the existing logReportJson() capability. Previously, evaluation results were either inaccessible (single-measure path didn't thread them to the test assertion layer) or discarded entirely (multi-measure path dropped them in toMeasureDefAndParametersResults()).

1. New logEvaluationResults() on SelectedMeasureDef: Logs pretty-printed CQL evaluation results (expression names, values, evaluated resources) per subject for a single measure, with separator lines between subjects for readability.
2. New logAllMeasureEvaluationResults() on SelectedMeasureDefCollection: Logs evaluation results for all measures in a multi-measure evaluation in a single formatted block, with separator lines between measures and subjects.
3. Evaluation results preserved in multi-measure path: MeasureDefAndR4ParametersWithMeasureReports now carries Map<MeasureDef, Map<String, EvaluationResult>>, and R4MultiMeasureService.toMeasureDefAndParametersResults() populates it instead of discarding the data.

Code Review Suggestions

• The evaluationResultsPerMeasure map in MeasureDefAndR4ParametersWithMeasureReports is keyed by MeasureDef reference identity (not equals()/hashCode()). Verify that the same MeasureDef instances flow from toMeasureDefAndParametersResults() through to SelectedMeasureDefCollection.get() without being copied or rebuilt, since a different instance with the same data would miss the map lookup.
• MeasureDefAndR4ParametersWithMeasureReports is annotated @VisibleForTesting but lives in src/main — confirm this is acceptable given that the new evaluationResultsPerMeasure field increases the data retained in this record beyond what production code needs.
• The formatMeasureEvaluationResults method on EvaluationResultFormatter is in production code (src/main) — verify this is the right home vs. a test utility, since it is only called from test classes.

QA Test Suggestions

Setup

This is test infrastructure only — no production behavior changes. QA validation is done by adding the new logging calls to existing integration tests and verifying output.

• Add .logEvaluationResults() to a single-measure test (e.g., in a test using Measure.given()), run the test, and verify that formatted evaluation results appear in the test log output at INFO level with separator lines between subjects.
• Add .logAllMeasureEvaluationResults() to a multi-measure test (e.g., in MultiMeasureServiceTest), run the test, and verify that results for all evaluated measures appear in a single log block with separator lines between measures and between subjects.
• Verify that a test using the 2-arg backward-compatible constructor path (no evaluation results available) logs (no evaluation results available) rather than throwing an exception.
• Verify that the existing .logReportJson() on SelectedMeasureReport continues to work as before and is unaffected by these changes.

[github-actions]

Formatting check succeeded!

[sonarqubecloud]

Quality Gate failed

Failed conditions
27.3% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud