Update to PDex Drug Formulary 1.1.0

[lmsurpre]

Is your feature request related to a problem? Please describe.
PDex Drug Formulary 1.1.0 was published last fall... its time we add that to our fhir-ig-pdex-formulary module.

Describe the solution you'd like
Add 1.1.0 alongside 1.0.1 ...similar to #3651 .

We should also move the corresponding examples from fhir-examples down to src/test/resources/examples/100 and add the new examples alongside those in a 110 directory.

Describe alternatives you've considered
Replace 1.0.1 with 1.1.0

Acceptance Criteria

1. GIVEN the fhir-ig-davinci-pdex-formulary jar is in userlib
   WHEN a resource is validated against an applicable profile with no version suffix (or specifies a version of 1.1.0)
   THEN validation uses the artifacts from PDex Drug Formulary 1.1.0

2. GIVEN the fhir-ig-davinci-pdex-formulary jar is in userlib
   WHEN a resource is validated against an applicable profile with a version id of 1.0.1
   THEN validation uses the artifacts from PDex Drug Formulary 1.0.1

Additional context

[lmsurpre]

Unfortunately, PDEX Drug Formulary 1.1.0 is not backwards compatible with version 1.0.1.

Currently, when the IBM FHIR Server sees an extension, it looks up the corresponding extension definition in the registry and checks for conformance. This happens outside of any profile validation.

However, because extension urls are never versioned, this means that we'll always look up the latest definition. This makes us quite sensitive to extension definitions that change over time.

In PDEX US Drug Formulary 1.1.0, the following extension values have changed from type string to type uri:

• http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-MarketingURL-extension
• http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-SummaryURL-extension
• http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-FormularyURL-extension
• http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-EmailPlanContact-extension

To further complicate matters, the code display names in many of the CodeSystems have changed as well:

• http://hl7.org/fhir/us/davinci-drug-formulary/CodeSystem/usdf-DrugTierCS
• http://hl7.org/fhir/us/davinci-drug-formulary/CodeSystem/usdf-CoinsuranceOptionCS
• http://hl7.org/fhir/us/davinci-drug-formulary/CodeSystem/usdf-CopayOptionCS
• http://hl7.org/fhir/us/davinci-drug-formulary/CodeSystem/usdf-PharmacyTypeCS

These CodeSystem are referenced from http://hl7.org/fhir/us/davinci-drug-formulary/StructureDefinition/usdf-DrugTierDefinition-extension and some are required.

These breaking changes mean that a valid 1.0.1 instance will be invalid in version 1.1.0 and, because we check extensions separate from profile validation, such instances will fail our validation just by having the 1.1.0 versions in the registry.

For this reason, I'm thinking that maybe we should split version 1.1.0 into a separate jar from 1.0.1 (or avoid packaging it altogether).
The alternative would be to try making our Validator more intelligent: if an extension url is mentioned in the profile, and the profile indicates a particular version of that extension, then only check against that version (and not the latest). This will be tricky because, as mentioned above, the extension validation happens independent of profile validation today.