[r4b] Support for generating a 4.0.1-compatible CapabilityStatement

[lmsurpre]

Is your feature request related to a problem? Please describe.
During connectathon, I noted that almost everyone was still using R4.
For almost all use cases, R4B should be backwards-compatible with R4.
R4 clients should be able to work with our R4B server.

However, one challenge we hit is that R4 clients are unable to parse our R4B CapabilityStatement due to a couple issues:

1. https://www.hl7.org/fhir/capabilitystatement-definitions.html#CapabilityStatement.fhirVersion has a required binding to https://www.hl7.org/fhir/valueset-FHIR-version.html and 4.3.0 is not in that list
2. https://www.hl7.org/fhir/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.type has a required binding to https://www.hl7.org/fhir/valueset-resource-types.html and the new R4B resource types are not on that list

Describe the solution you'd like
If a client tries to retrieve our CapabilityStatement with an Accept header that indicates they are using version 4.0 (or 4.0.1), make the following changes to our generated CapabilityStatement:

1. advertise 4.0.1 in the CapabilityStatement instead of 4.3.0
2. omit resource types that didn’t exist in 4.0.1

Note that we cache these CapabilityStatements on a per-tenant basis, so for this to work I think we'd need to add the fhir version to the cache's key.

Describe alternatives you've considered
Always generate a 4.3.0 CapabilityStatement and suggest clients update to handle it.

Acceptance Criteria

1. GIVEN a 5.0.0-SNAPSHOT server
   AND a 4.x client (e.g. our fhir-client from 4.11.1)
   WHEN the client invokes /metadata without specifying the fhirVersion
   THEN it can successfully parse the response (i.e. only R4 resource types are present in the CapabilityStatement)

Also:

1. GIVEN a 5.0.0-SNAPSHOT server
   AND /fhirserver/core/defaultFhirVersion is set to 4.0 (the default)
   WHEN the client invokes /metadata without specifying the fhirVersion
   THEN the CapabilityStatement says the server supports FHIR version 4.0.1

2. GIVEN a 5.0.0-SNAPSHOT server
   AND /fhirserver/core/defaultFhirVersion is set to 4.0 (the default)
   WHEN the client invokes /metadata with an accept header of application/fhir+json;fhirVersion=4.3
   THEN the CapabilityStatement says the server supports FHIR version 4.3.0-cibuild

3. GIVEN a 5.0.0-SNAPSHOT server
   AND /fhirserver/core/defaultFhirVersion is set to 4.3
   WHEN the client invokes /metadata without specifying the fhirVersion
   THEN the CapabilityStatement says the server supports FHIR version 4.3.0-cibuild

4. GIVEN a 5.0.0-SNAPSHOT server
   AND /fhirserver/core/defaultFhirVersion is set to 4.3
   WHEN the client invokes /metadata with an accept header of application/fhir+json;fhirVersion=4.0
   THEN the CapabilityStatement says the server supports FHIR version 4.0.1

Additional context
some related discussion at https://chat.fhir.org/#narrow/stream/179166-implementers/topic/R4B.20technical.20corrections

[lmsurpre]

A related complication: A few of the R4B resource types are incompatible with their R4 equivalents.

• DeviceDefinition
• Evidence
• EvidenceVariable

For these ones, our 5.0 server implementation will only support the R4B flavor of these.
Therefor, I'm thinking to remove these from the 4.0.1 flavor of our CapabilityStatement.

There's also a potential breaking change on the ActivityDefinition and PlanDefinition resource types if a 4.3.0 client creates instances of these with the new subjectCanonical choice type element. Should we remove those from the 4.0.1 flavor of the CapabilityStatement as well?

Some related discussion at
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/R4B.20compatibilty/near/269414682

[lmsurpre]

Test note: verify that we ignore fhir-server-config resources config values that are no longer valid in R4B.