Fix repository search parameter detection and offload support

[JPercival]

The RepositoryRetrieveProvider is the component that determines whether a given CQL query can be supported by and underlying platform, and emits requests accordingly. For example, the following CQL query:

context Patient
[Observation: code in "ValueSet']

could naively be transformed into the following REST request:

/Observation?subject=XYZ&code:in=https://example.com/ValueSet/1

However, not every FHIR platform supports the necessary search parameters. Some platforms allow detection of which search parameters are supported based on metadata available in the CapabilityStatement. The RepositoryRetrieveProvider has some logic to be able to customize the query based on the supported search parameters and, if necessary, would implement a less efficient client-side filter in the event a search parameter was unsupported. This is currently broken and needs to be fixed.

As an additional consideration, not all platforms correct implement the CapabilityStatement functionality, so there needs to be some configuration available to force the RepositoryRetrieveProvider to either offload all queries (regardless of native support) or do all filtering in memory (again, regardless of platform support).

This is particularly important in the context of CDS, since the cds-hooks specification has a fhirEndpoint parameter that allows callback to a given EHR to collect additional data if necessary. EHRs "in the wild" vary widely in the completeness of their implementation of the FHIR REST specification.

[JPercival]

For the short term we added a set of configuration options in #347 .