Built-in Profiles for CapabilityStatement.instantiates entry for the "supported"

[prb112]

Is your feature request related to a problem? Please describe.
Built-in Profiles for CapabilityStatement.instantiates entry for the "supported" implementation guides on the server.

Describe the solution you'd like

• Add support with Built-in Profiles for CapabilityStatement.instantiates entry for the "supported"
• Consider adding bulkdata to this as an extended / supported ig - note this is not necessarily correct, will have to carefully evaluate the addition to the capability statement - https://jira.hl7.org/browse/FHIR-26683?jql=text%20~%20%22capabilitystatement%20instantiates%22

Describe alternatives you've considered
None

Additional context
None

[lmsurpre]

Troy and I discussed a couple different options on this one.

1. driving the "instantiates" for a simple array of strings from the fhir-server-config.json
2. retrieving all CapabilityStatement resources from the fhir-registry and constructing canonicals from the url+version fields of those resources

An advantage of number 1 is that it could be tenant-aware, so that each tenant can advertise a different set of IGs.
However, we already populate the profiles that are supported for each resource type from the registry (and its not tenant-aware). Also currently the validator is using all registered resources (and not just a subset).

Therefore, lets pursue option 2 at this time so that it is the most consistent with the rest of the working system.

The one place where the system is tenant-specific (wrt support for a specific IG) is the bulk data support.
However, we already have that one hardcoded in our CapabilityStatement and so we'll be no worse than we are today.
Therefore, lets update the fhir-operation-bulkdata project to provide a RegistryResourceProvider that provides just the bulkdata CapabilityStatement from https://hl7.org/fhir/uv/bulkdata/CapabilityStatement-bulk-data.html, and--if this operation jar is present--always advertise the capability (even if the tenant does not have it confiured).

We can revisit this decision if/when we implement #1449 and/or decide that we need to filter the list of all CapabilityStatements down to just some configured list (on a per-tenant basis or otherwise).