Scope whole-system interactions to the intersection of R4 and R4B by default

[lmsurpre]

Is your feature request related to a problem? Please describe.
Building on the support added in #3137 ...

For example, for whole-system history:

• IBM FHIR Server 5.0 is deployed and instances of the new resource types are added to it
• An existing R4 client invokes whole-system history and, when they get to the page with the new resource type, they are unable to parse the response.

Similar scenarios exist for whole-system search and $export (and maybe $everything as well?)

Describe the solution you'd like
Introduce a fhir-server-config property that controls the server behavior when no fhirVersion is specified by the client. The default value for this property should result in the server only returning 4.0.1 resource types (but still not ones removed in 4.3.0).

Regardless of the setting, if the client passes an Accept header with a FHIR mime type that includes fhirVersion=4.3, and the new resource types are not filtered out in the fhir-server-config resources section, then include the new resource types introduced in R4B.

This is consistent with the CapabilityStatement behavior implemented for #3192 except that we should update that to support changing the default if the user wants something other than 4.0.1 to be the default behavior.

Describe alternatives you've considered
Force the IBM FHIR Server operator to explicitly list the set of supported resource types in their fhir-server-config and use exactly that set when the client doesn't pass any fhirVersion in their Accept header.
If they only want to server 4.0 resource types, then only list 4.0 resource types and set open=false.

If the client explicitly asks for fhirVersion=4.0 we could still omit all the resource types introduced in R4B.

If we went with this alternative, we'd need to update the CapabilityStatement behavior to match because, currently, that defaults to omitting the new R4B resource types (unless fhirVersion=4.3 is passed)

Acceptance Criteria

1. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a whole-system history query is sent with no explicit _type parameter
   AND the client sets the Accept header to application/fhir+[xml/json];fhirVersion=4.3
   THEN the history response contains the R4B resource types

2. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a whole-system search query is sent with no explicit _type parameter
   AND the client sets the Accept header to application/fhir+[xml/json];fhirVersion=4.3
   THEN the search response contains the R4B resource types

3. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a system-level $export interaction with no explicit _type parameter
   AND the client sets the Accept header to application/fhir+[xml/json];fhirVersion=4.3
   THEN the $bulkdata-status response contains a download url for the R4B resource types

4. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a whole-system history query is sent with no explicit _type parameter
   AND the client does NOT set the Accept header / sets it to application/fhir+[xml/json]
   THEN the history response does NOT contains the R4B resource types

5. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a whole-system search query is sent with no explicit _type parameter
   AND the client does NOT set the Accept header / sets it to application/fhir+[xml/json]
   THEN the search response does NOT contains the R4B resource types

6. GIVEN a 5.0 IBM FHIR Server with resource type instances of types added in R4B (e.g. Ingredient)
   WHEN a system-level $export interaction with no explicit _type parameter
   AND the client does NOT set the Accept header / sets it to application/fhir+[xml/json]
   THEN the $bulkdata-status response does NOT contains a download url for the R4B resource types

Additional context
Similar to #3192 but for system interactions and not just the CapabilityStatement

[lmsurpre]

Introduce a fhir-server-config property that controls the server behavior when no fhirVersion is specified by the client. The default value for this property should result in the server only returning 4.0.1 resource types (but still not ones removed in 4.3.0).

This could easily be implemented in the same spot we set the default Accept header to application/fhir+json when none is passed (FHIRHttpServletRequestWrapper?)