Support _total with _include and _revinclude

[tbieste]

Is your feature request related to a problem? Please describe.
In SearchUtil.java we have the following code snippet:

        // Make sure _total is not present with _include and/or _revinclude.
        // TODO: do we really need to forbid this?
        if (queryParameters.containsKey(SearchConstants.TOTAL)) {
            throw SearchExceptionUtil.buildNewInvalidSearchException(
                    "_total search result parameter not supported with _include or _revinclude.");
        }

Since _sort has a similar restriction, #1915, figured enhancing to support this combination can be deferred as well.

Describe the solution you'd like
Need a way to determine the number of matched vs include resource returned by the query when the total resource count is not available due to the countQuery being skipped.

Describe alternatives you've considered
Continue to disable the use of these parameters together.

Additional context
I think there would be a way to determine matchedCount vs includeCount without needing the total count by adding an "includedRsrc" field to the ResourceDTO since the underlying query does use a SORT_ORDER column to ensure included resources are returned after matched resources. The base query would need to be updated to surface the SORT_ORDER (and maybe rename it to INCLUDE_TYPE or something). Then the matchedCount vs includeCount can just be calculated from the returned ResourceDTOs.

[tbieste]

Due to the implementation of issue #1158, the matchCount and includeCount no longer need to be calcuated from the total count. This issue now should only have to enable the parameters to be used together.

[michaelwschroeder]

I have exercised this functionality on my local development system running the latest codebase, and have verified that it works correctly with both _include and _revinclude searches