Support CodeSystem validation as part of instance validation

[lmsurpre]

Is your feature request related to a problem? Please describe.
The IBM FHIR Server is now capable of validating valueset membership for all codes/codings/codeableconcepts which include a binding of preferred or stronger (barring #1216).

However, it would be additionally helpful to know that a given code is actually valid within a given system in cases where it is NOT part of a valueset.

In the past, we considered this to be the territory of a formal "terminology server" but now that we have some basic terminology services implemented (including CodesSystem/$validate), we should have what we need to validate these codes (or provide a warning if they can not be validated due to a CodeSystem that is not fully specified).

Describe the solution you'd like
As a FHIR Server operator, I would like to have the option of enabling codesystem validation so that I know that all instances received by the server include valid content.

There will likely be a performance cost to this and so I think it would be good to make it configurable, but hopefully we can make it fast enough to enable this validation by default.

If a given code cannot be validated against a given codesystem, I think we should emit some kind of supplemental issue (either warning or informational). However, we should probably avoid this check altogether if it exists in a configured valueset already.

Describe alternatives you've considered
I wonder if we should validate valuesets themselves or if we should trust whatever is in a valueset to be valid...

[lmsurpre]

We should have support for "syntax-based" codesystems like languages (bcp47) and ucum.
Also, there is an interesting consideration here wrt instances of type code which have an "implicit system".

[lmsurpre]

I think this issue is also related to #745 in that, potentially, the CodeSystem $validate-code could reach out to external terminology services (for select codesystems).

[JohnTimm]

Since, we currently cache binding information in ProfileSupport:

    private static Map<String, Binding> computeBindingMap(String url) {
        StructureDefinition structureDefinition = getStructureDefinition(url);
        if (structureDefinition != null) {
            Objects.requireNonNull(structureDefinition.getSnapshot(), "StructureDefinition.snapshot element is required");
            Map<String, Binding> bindingMap = new LinkedHashMap<>();
            for (ElementDefinition elementDefinition : structureDefinition.getSnapshot().getElement()) {
                String path = elementDefinition.getPath().getValue();
                Binding binding = elementDefinition.getBinding();
                if (binding != null) {
                    bindingMap.put(path, binding);
                }
            }
            return Collections.unmodifiableMap(bindingMap);
        }
        return Collections.emptyMap();
    }

if we the current visitor path in the validator and make it a "simple path" (one that doesn't have indices), we could use a heuristic to figure out whether there is a binding for the element at that path for any profiles asserted by the resource. It wouldn't be foolproof but reasonable compared to validating all codes and having to live with double validation.

[lmsurpre]

Random thought: If we could assume that only validated system+code values have been written to the common-token-values table (and the corresponding caches), then we could use our existing caches to validate codes as well.
Or maybe that doesn’t rally help because we’d still need to go to the codesystem resource to validate the Display text and version (when present).

[lmsurpre]

On the subject of version verification, we should make sure we’re enforcing this:

When the CodeSystem.versionNeeded is 'true', then the version identifier SHALL be used in Coding instances that refer to the code system.

And we should make sure we’re using the version in search (either by adding it to common-token-values or ensuring we use it from xx-token-value-refs).