fix(terminology): $validate-code pins one code system version before it checks the display

[rubentalstra]

When a value set includes two versions of the same code system, $validate-code
pins one of them before it checks the display, so a coding that is valid under
the other version fails.

http://hl7.org/fhir/test/ValueSet/overload-all of the terminology ecosystem
suite includes overload|1.0.0 and overload|2.0.0. In 1.0.0 code2 displays
"Display 2"; in 2.0.0 it displays "Display #2". A Coding of code2 with
"Display 2" and no version is a member of that value set through the 1.0.0
include, with the display that include's version states, so the answer is
result = true with version = 1.0.0. The server answers result = false with
version = 2.0.0 and an invalid-display issue.

R5 states the input as "A coding to validate. The system must match the
specified code system"
(tools/fhir-codegen/vendor/hl7.fhir.r5.core/package/OperationDefinition-ValueSet-validate-code.json),
and the version output as "The version of the system of the code that was
validated": the version reported is the one the code actually validated in, so
the choice among the versions a value set includes belongs to the validation,
not before it. crates/fhir-terminology/src/operations/value_set_validate_code.rs
already has containing_version, which picks the first version holding the
code; it needs to prefer a version that also accepts the asserted display, and
the same choice governs which version an exclude at another version removes.

Five general cases turn on this: overload/validate-good2a,
overload/validate-good-code2-v1display, overload/validate-bad-exclude-code1,
overload/validate-bad-v1code4, and overload/validate-bad-v2code3.

Acceptance criteria

• When several versions a value set includes hold the code, the validation
  picks the one under which the coding is valid, and reports that version.
• A test pins the choice, over a synthetic code system in two versions whose
  displays differ.
• The five overload cases pass on /r4b, /r4, and /r5 and join the
  committed pass lists.

[rubentalstra]

Fixed in #458, which carries all three of the $validate-code defects that
live in the same file.

The five cases turned out to be three separate readings of the same rule, that
version is "The version of the system of the code that was validated"
(OperationDefinition-ValueSet-validate-code.json, hl7.fhir.r5.core 5.0.0).

1. The version choice. containing_version now prefers a version that
   holds the code in the value set AND accepts the display the coding asserts,
   then one that holds the code, then the greatest included version.
   validate-good2a and validate-good-code2-v1display.
2. The exclude. ValueSet.compose.exclude is "Exclude one or more codes
   from the value set" and include.version is "The version of the code system
   that the codes are selected from"
   (https://hl7.org/fhir/R4B/valueset-definitions.html#ValueSet.compose.exclude),
   so the version on an exclude selects its codes rather than matching the
   entry an include contributed. Expander::contains no longer applies the
   requested-version guard to an exclude. validate-bad-exclude-code1.
3. The membership issue names the code the way the request stated it, the
   version included, which the CodeableConcept path already did and the
   single-coding path did not. validate-bad-v1code4 and validate-bad-v2code3
   differ on that one string and on nothing else, so they were text rather than
   selection; the three |version#code expectations in the whole suite are
   those two and version/simple-codeableconcept-bad-version2, which stays
   open for another reason.

All five pass on /r4b, /r4, and /r5 and are on the three pass lists.
crates/fhir-terminology/tests/it/value_set.rs pins all three over a synthetic
code system in two versions whose code2 display differs, in a value set that
includes both and in one that includes the second and excludes the first.