BulkData 2.0.0: _type query parameter's cardinality is relaxed

[prb112]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

BulkData 2.0.0: _type query parameter's cardinality is relaxed.
http://hl7.org/fhir/uv/bulkdata/OperationDefinition-export.html

Current cardinality is:

    {
      "name": "_type",
      "use": "in",
      "min": 0,
      "max": "1",
      "documentation": "A string of comma-delimited FHIR resource types. Only resources of the specified resource types(s) SHOULD be included in the response. If this parameter is omitted, the server SHOULD return all supported resources within the scope of the client authorization. Resource references MAY be relative URIs with the format <resource type>/<id>, or absolute URIs with the same structure rooted in the base URI for the server from which the export was performed. References will be resolved looking for a resource with the specified type and id within the file set. Note: Implementations MAY limit the resources returned to specific subsets of FHIR, such as those defined in the Argonaut Implementation Guide.",
      "type": "string"
    },

IN | _type | 0..* | string |   | Support is optional for server and a client. 

Support is optional for a server and a client.

A string of comma-delimited FHIR resource types.

The response SHALL be filtered to only include resources of the specified resource types(s).

If this parameter is omitted, the server SHALL return all supported resources within the scope of the client authorization, though implementations MAY limit the resources returned to specific subsets of FHIR, such as those defined in the US Core Implementation Guide. For groups of patients, the Patient Compartment SHOULD be used as a point of reference for recommended resources to be returned. However, other resources outside of the Patient Compartment that are referenced by the resources being returned and would be helpful in interpreting the patient data MAY also be returned (such as Organization and Practitioner). When this behavior is supported, a server SHOULD document this support (for example, as narrative text, or by including a GraphDefinition Resource).

A server that is unable to support _type SHOULD return an error and FHIR OperationOutcome resource so the client can re-submit a request omitting the _type parameter. If the client explicitly asks for export of resources that the Bulk Data server doesn't support, or asks for only resource types that are outside the Patient Compartment, the server SHOULD return details via a FHIR OperationOutcome resource in an error response to the request. When a Prefer: handling=lenient header is included in the request, the server MAY process the request instead of returning an error.

For example _type=Observation could be used to filter a given export response to return only FHIR Observation resources.

fhir-smart checkSystemScopes needs to be updated

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Acceptance Criteria

1. GIVEN [a precondition]
   AND [another precondition]
   WHEN [test step]
   AND [test step]
   THEN [verification step]
   AND [verification step]

Additional context
Make sure to update the fhir-smart interceptors beforeInvoke logic to handle this too!

[prb112]

QA: run with multiple _types and duplicate entries don't result in multiplicative output.

[d0roppe]

Seems to be working with only exporting what is in _type, and not duplicating even if you specify the same resource multiple times.