Investigate approach to offering most appropriate CapabilityStatement for given use cases

[lmsurpre]

relates to #1315

[lmsurpre]

A few approaches for this one.
A. drive it from the CapabilityStatement resources in the registry
B. drive it from fhir-server-config.json
C. a hybrid approach where the combination of all the CapabilityStatements in the registry is the full functionality of the server and then the fhir-server-config config filters that down
D. move to a static approach where the operator creates a CapabilityStatement to their liking and configures the server to share that directly (not even using the registry)

	pro	con
registry	more consistent with our approach for validation and for advertising IG support (#1315), more consistent with the FHIR Specification (avoids inventing our own CapabilityStatement-like JSON structure)	less support for tenant-specific config, harder to implement (requires "merge" logic that combines the various CapabilityStatements)
config	more consistent with our approach of generating the CapabilityStatement from our config, simpler to develop, simpler to understand for operators, tenant-specific config already works
hybrid	like the registry approach, except it provides a way to resolve conflicts in the configured CapabilityStatements	complicated
static	simple	a complete reversal of our current approach to generating the config, totally divorced from the fhir-server behavior unless we make a whole set of sweeping changes to drive behavior from CapabilityStatement instead of fhir-server-config.json

We might want to combine this with #1272 if we decide to drive this from the config (option B).

For example, we could potentially combine the two through a structure like this:

"resources": {
  "includeOmittedResourceTypes": false,
  "ExplanationOfBenefit": {
    "interactions": ["read", "vread", "history", "search"],
    "searchParameters": [
        "http://hl7.org/fhir/us/carin-bb/SearchParameter/explanationofbenefit-patient",
        "http://hl7.org/fhir/us/carin-bb/SearchParameter/explanationofbenefit-type",
        "http://hl7.org/fhir/us/carin-bb/SearchParameter/explanationofbenefit-identifier",
        "http://hl7.org/fhir/us/carin-bb/SearchParameter/explanationofbenefit-service-date"
    ]
  },
  "Organization": {
    "interactions": ["read", "vread", "history", "search"],
    "searchParameters": [
    ]
  },
  "Resource": {
    "searchParameters": [
        "http://hl7.org/fhir/SearchParameter/Resource-id",
        "http://hl7.org/fhir/SearchParameter/Resource-lastUpdated"
    ]
  }
}

[lmsurpre]

Generating the capability statement from the config seems to be working. I opened #1615 for using this new config to drive server behavior.