Improve design for configuring profile conformance checking

[lmsurpre]

Is your feature request related to a problem? Please describe.
In #1547 we introduced a config property: fhirServer/resources/<resourceType>/profiles/atLeastOne

As documented at https://ibm.github.io/FHIR/guides/FHIRServerUsersGuide#453-profile-validation, setting this property causes us to:

1. Validate that at least one profile in the list is specified in the resource’s meta.profile element
2. Validate that all profiles specified in the resource’s meta.profile element are supported by the FHIR server
3. Validate that the resource’s data conforms to all profiles specified in the resource’s meta.profile element

However, I think points 2 and 3 there are confusing/unexpected behavior for a property named atLeastOne.

For example, consider this scenario:

• resource comes in claiming conformance to profile1 and profile2
• server knows about profile1 but not profile2

with no atLeastOne prop, we accept the resource, validate against profile1, and emit a warning about profile2.

with atLeastOne: [profile1], we would now reject this resource, despite it having the required profile

Describe the solution you'd like
Introduce a new config property that controls whether or not the server allows for resources that claim conformance to unknown profiles (aka profiles it can't check conformance to because they are not in the registry).

Something like: fhirServer/resources/<resourceType>/profiles/allowUnknown (with a default value of true).

I doubt we need it at a per-resource-type basis, but if we supported it at this level, users could just use the "Resource" section to set it for all resource types.

Describe alternatives you've considered
Introduce fhirServer/resources/<resourceType>/profiles/allowed (to go along with the notAllowed list from #2871 ).

Acceptance Criteria

1. GIVEN server knows about profile1 but not profile2
   AND a create resource request comes in with a resource that claims conformance to profile1 and profile2
   WHEN allowUnknown is true (default)
   THEN the resource is successfully validated against profile 1 and a warning is issued to state it couldn't be validated against profile2

2. GIVEN server knows about profile1 but not profile2
   AND a create resource request comes in with a resource that claims conformance to profile1 and profile2
   WHEN allowUnknown is false
   THEN the request is rejected with a reasonable error message that explains that profile2 isn't supported

Additional context
A separate idea/question I had is whether we want to let users configure a set of implicit profiles that we could check against whether the resource instance claims conformance to these or not... maybe a separate enhancement request?

[lmsurpre]

I confirmed by setting allowUnknown at just the "Resource" endpoint, then by setting it on the "Patient" endpoint. it worked as described in the user's guide.

test results for ingestion:

allowUnknown	Resource.meta.profile	result
false	["profile1"]	400 Bad Request with "Profile 'profile1' is not supported"
false	["profile1|a"]	400 Bad Request with "Profile 'profile1
false	["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"]	200 OK
false	["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient|3.1.1"]	200 OK
false	["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient|bogus"]	200 OK
false	["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient|3.1.1"]	400 Bad Request with "Profile 'http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient

notably, the setting does NOT cause the $validate endpoint to return an error when a resource claims conformance to an unknown profiile. that was never really discussed and so I think this behavior is fine, but i wanted to make sure it was clear that the server will still try to validate against the "notAllowed" profiles at this alternate endpoint