FHIRPath conformsTo loops can lead to StackOverflow

[lmsurpre]

Describe the bug
When a given profile contains a profile reference type constraint (e.g. saying that reference A must be a reference to a resource of type B--where B is a profile of a standard resource type) and that profile contains a reference type constraint back to A (either directly or through one or more other profiles), it is possible for the FHIRValidator to get into an endless loop.

Environment
In 4.8.2, this issue was limited to cases where there are loops within a single resource (e.g. outer resource references the inner resource and the inner resource references the outer one).

In 4.8.3, we added a configuration option which allows the FHIRPath engine to resolve resource references from the database (fhirServer/core/serverResolveFunctionEnabled). When enabled, this expands the number of scenarios where we could hit this issue.
However, in the same timeframe, we also added an optimization which avoids redundant checking of resources when a resource claims conformance to the profile being checked via its Resource.meta.profile ).
Therefore, this issue will only be seen in 4.8.3 when all resource instances in the loop are missing the profile we are checking against in their Resource.meta.profile.

To Reproduce
Steps to reproduce the behavior:

1. Create profiles A and B that each have a reference type constraint which points to instance of the other
2. Create an instance of A that has a contained instance B with references to one another (e.g. "reference": "#b" in A and "reference": "#" in B)
3. Validate resource A

Note the StackOverflow error.

Expected behavior
It successfully validate the resource

Additional context
While most FHIR resources are modeled to avoid this kind of circular reference issue, it is explicitly allowed for by the spec: https://www.hl7.org/fhir/references.html#circular

[lmsurpre]

The associated unit test and existing integration tests are sufficient.