Handling of system.long addressed

[bryantaustin13]

---

Moved from #96, which was raised from a fork before I had committer access on this repository. Same work, same branch name, now hosted here so CI and reviews run against cqframework directly.

Note: #96 carried an approval that predates #106 and #110, both of which have since landed and rewritten resultsEqual and extractor-builder.ts. This branch conflicts with current main and needs re-scoping before it is reviewable — do not treat the old approval as current.

[bryantaustin13]

Carried over from #96

This PR replaces #96, which was raised from a fork. Reproducing the discussion verbatim,
since it did not move across and the central question is unresolved:

@cmoesel (2026-04-23):

@brynrhodes - Why should we skip tests with Longs for R4? There is a mapping for CQL Long to R4. Given that the mapping exists and is R4-compliant, there is no reason a compliant CQL server could not return Long results in R4 (and, in fact, the javascript engine does).

The real problem is that the test runner doesn't correctly detect equality for Longs. See #79.

---

@bryantaustin13 (2026-04-24):

See cqframework/clinical_quality_language#1750 for engine handling of R4 system.long. This branch should handle the cases of the different FHIR and CQL versions in regards to system.long. So it is currently failing for R4.

---

@brynrhodes — review APPROVED (2026-04-23):

This is great that it uses the capability statement to get the fhir version, but skipping

---

Status: the approval above predates #106 and #110, both since merged, which rewrote
resultsEqual and extractor-builder.ts. This branch conflicts with current main on
extractor-builder.ts, results-shared.ts and results-utils.ts, and #106 already landed
Long-as-valueString support. @cmoesel's question — why skip Long tests on R4 when an
R4-compliant mapping exists — should be settled before this is re-scoped, since it may make
the branch unnecessary.