split FHIR 4.0.1 conformance artifacts into separate module and exclude by default

[lmsurpre]

Is your feature request related to a problem? Please describe.
After rebasing onto the latest from main, I noticed our build logs filling with messages like the following:

2022-03-09T16:36:39.7405501Z WARNING: Replacing http://hl7.org/fhir/SearchParameter/clinical-patient|4.0.1 [AllergyIntolerance.patient | CarePlan.subject.where(resolve() is Patient) | CareTeam.subject.where(resolve() is Patient) | ClinicalImpression.subject.where(resolve() is Patient) | Composition.subject.where(resolve() is Patient) | Condition.subject.where(resolve() is Patient) | Consent.patient | DetectedIssue.patient | DeviceRequest.subject.where(resolve() is Patient) | DeviceUseStatement.subject | DiagnosticReport.subject.where(resolve() is Patient) | DocumentManifest.subject.where(resolve() is Patient) | DocumentReference.subject.where(resolve() is Patient) | Encounter.subject.where(resolve() is Patient) | EpisodeOfCare.patient | FamilyMemberHistory.patient | Flag.subject.where(resolve() is Patient) | Goal.subject.where(resolve() is Patient) | ImagingStudy.subject.where(resolve() is Patient) | Immunization.patient | List.subject.where(resolve() is Patient) | MedicationAdministration.subject.where(resolve() is Patient) | MedicationDispense.subject.where(resolve() is Patient) | MedicationRequest.subject.where(resolve() is Patient) | MedicationStatement.subject.where(resolve() is Patient) | NutritionOrder.patient | Observation.subject.where(resolve() is Patient) | Procedure.subject.where(resolve() is Patient) | RiskAssessment.subject.where(resolve() is Patient) | ServiceRequest.subject.where(resolve() is Patient) | SupplyDelivery.patient | VisionPrescription.patient] with http://hl7.org/fhir/SearchParameter/clinical-patient|4.3.0-CIBUILD [AllergyIntolerance.patient | CarePlan.subject.where(resolve() is Patient) | CareTeam.subject.where(resolve() is Patient) | ClinicalImpression.subject.where(resolve() is Patient) | Composition.subject.where(resolve() is Patient) | Condition.subject.where(resolve() is Patient) | Consent.patient | DetectedIssue.patient | DeviceRequest.subject.where(resolve() is Patient) | DeviceUseStatement.subject.where(resolve() is Patient) | DiagnosticReport.subject.where(resolve() is Patient) | DocumentManifest.subject.where(resolve() is Patient) | DocumentReference.subject.where(resolve() is Patient) | Encounter.subject.where(resolve() is Patient) | EpisodeOfCare.patient | FamilyMemberHistory.patient | Flag.subject.where(resolve() is Patient) | Goal.subject.where(resolve() is Patient) | ImagingStudy.subject.where(resolve() is Patient) | Immunization.patient | List.subject.where(resolve() is Patient) | MedicationAdministration.subject.where(resolve() is Patient) | MedicationDispense.subject.where(resolve() is Patient) | MedicationRequest.subject.where(resolve() is Patient) | MedicationStatement.subject.where(resolve() is Patient) | NutritionOrder.patient | Observation.subject.where(resolve() is Patient) | Procedure.subject.where(resolve() is Patient) | RiskAssessment.subject.where(resolve() is Patient) | ServiceRequest.subject.where(resolve() is Patient) | SupplyDelivery.patient | VisionPrescription.patient]

Because each SearchParameter is now in the registry twice (once for 4.0.1 and once for 4.3.0), we get a conflict on every one.

Describe the solution you'd like
Move the 4.0.1 conformance artifacts from the registry to a separate module and do not include that in the server by default.
If that proves problematic, consider moving just the SearchParameters out.

Describe alternatives you've considered
Add some kind of feature to just always use the newer search parameter definition by default.

Acceptance Criteria

1. GIVEN a 5.0.0-SNAPSHOT server with no its default config
   WHEN the server starts
   THEN there should be no warnings in the logs during startup (or at least they should be minimal)

Additional context
I thought that we used 4.0.1 structure definitions while validating profiles but, based on local testing, that doesn't actually seem to be the case. I think because we use the snapshot and not the differential, having just the profile (without the StructureDefinition on which its based) is sufficient for runtime validation.

The only time we should need the actual 4.0.1 StructureDefinitions is if we're using a utility like our ProfileBuilder or ExtensionBuilder to actually build new profiles.

We should probably also package up the latest HL7 terminologies into a separate jar. These used to be distributed with the FHIR specification but now they have their own separate packaging. separate issue?

[lmsurpre]

While investigating this one, I found some rather significant changes in the way v2 and v3 codesystems are represented in FHIR.

Firstly, the v3 codesystems now use a property-based hierarchy instead of a nested-code hierachy. I opened #3448 for that one, but I think we can do without it if we package the pre-expanded valuesets that are downloadable from the r4b downloads page.

Second, at least the v2 codesystems (and maybe others) now indicate that they are caseSensitive. Previously they were missing this element and, in these cases, our implementation assumed them to be not case-sensitive.
This means that we'll need to re-index to get the proper casing in the db for all affected codesystems.

[lmsurpre]

After current PR is approved and merged to r4b branch:

• separate issue for partially expanded valuesets
  • remove from expansions.json
  • update server logic to avoid this when computing isExpaned
• add fhir-core-r4 and fhir-hl7-terminology to the CI and release workflows
  • my assumption is fhir-core-r4b will be automatically covered since its now a module under fhir-parent

[d0roppe]

Verified based on acceptance criteria. Closing issue