Fix stratum value placement for component-based stratifiers (CDO-656)

[lukedegruchy]

For Measure stratifiers declared with stratifier.component[], the resulting MeasureReport put the stratum value at stratum.value instead of inside stratum.component[].value. Multi-component stratifiers worked by accident; a single component fell through to the non-component path because the gate was valueDefs.size() > 1.

Drive the output shape from the Measure definition (stratifierDef.components()), not the runtime value count, in both R4StratifierBuilder.buildStratum and R4MeasureReportUtils .matchesStratumValue. Also populate stratum.component[].id from the Measure component def.

Example - non-subject value stratifier (Encounter basis):

CQL:

    define function "Age Function" (e Encounter):
        AgeInYearsAt(start of e.period)

Measure.stratifier:

{ 
   "id": "stratifier-age", 
   "code": { "text": "Age" },
   "component": [
   {
        "id": "strat-1-comp-1",
        "code": { 
             "text": "Age" 
        },
        "criteria": { 
              "language": "text/cql.identifier",
              "expression": "Age Function" 
        }
    }
    ]
}

MeasureReport.stratum, before:

{ 
  "value": { 
         "text": "35" 
   }, 
   "population": 
    [ ... ] 
}

MeasureReport.stratum, after:

{ 
"component": [
    {
        "id": "strat-1-comp-1",
        "code":  { "text": "Age" },
        "value": { "text": "35" }
    }
   ],
   "population": [ ... ] 
}

Behavior change: consumers reading stratum.value.text for single-component stratifiers must now read
stratum.component[0].value.text. DSTU3 is unaffected (no stratifier.component in spec); no dedicated R5 builder exists.

[github-actions]

Formatting check succeeded!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
87.5% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud