SMART interceptor should enforce scope permissions up front

[lmsurpre]

Describe the bug
Because SMART scopes are only enforced on resources on their way out of the FHIR server, it is possible for an application with a valid access token to obtain information about the presence (or absence) of resource types for which they have not been granted read access.

Environment
Which version of IBM FHIR Server?

To Reproduce
Steps to reproduce the behavior:

1. load a server with some AllergyIntolerance for a patient
2. configure that server with the fhir-smart jar
3. obtain a token with a patient_id claim for that patient but no scope permitting read access to AllergyIntolerancce
4. perform search
5. obtain a token with a patient_id claim for some other patient with no AllergyIntolerance
6. perform search

Not that a search that returns the AllergyIntolerance comes back with a 403 whereas the other comes back with a 200 (with no results).

Expected behavior
A client app without read permission for a given resource type should not be able to infer whether or not any such resources exist.

Additional context
Add any other context about the problem here.

[lmsurpre]

One of the questions I had while implementing this is whether it should apply only to patient compartment resources (e.g. Condition, Observation) or whether it should also apply to non-compartment resources like Practitioner and Organization.

It wasn't super clear to me whether the existing afterX methods checked the scope string for these non-patient-compartment resources or not, but after reviewing https://chat.fhir.org/#narrow/stream/179170-smart/topic/Authorization.20for.20transactions/near/213305185 I felt that it would make the most sense to check the scope string for non-patient-compartment resources in the beforeX methods as well.

Therefore, to invoke read/vread/search/history against ANY resource type's endpoint, it is now definitively required to include the corresponding resourceType (or *) in the list of granted resource types. For example, to read an Organization resource, the user must have granted an application one of patient/Organization.read, patient/*.read, user/Organization.read, or user/*.read. (however, use of user/ permissions is still not implemented for some cases.

[kmbarton423]

Walked thru the test of this one with Lee using his Alvearie demo environment. Confirmed appropriate behaviors with and without limited scope when attempting to access (read/search) non-Patient compartment resources.