Combine url parameters with body parameters when extended ops are invoked via POST

[lmsurpre]

Is your feature request related to a problem? Please describe.
Most operations can be invoked via either GET or POST.

For GET requests, our "doInvoke" operation logic converts the URL parameters into a Parameters object.
For POST requests, we use the Parameters object passed in the body and ignore any URL parameters.

From FHIRRestHelper:

                if (resource == null) {
                    // build parameters object from query parameters
                    parameters =
                            FHIROperationUtil.getInputParameters(operation.getDefinition(), queryParameters);
                } else {
                    // wrap resource in a parameters object
                    parameters =
                            FHIROperationUtil.getInputParameters(operation.getDefinition(), resource);
                }

In some cases, it would be nice to add query parameters to a POST request.

For example, we support a "shortcut" syntax for requests that have a single input parameter named "resource" where they can pass just the input resource (without wrapping it in a Parameters object). In these cases it would be especially nice if you could add simple parameters to the query string.

For example:

curl --request POST \
  --url 'https://localhost:9443/fhir-server/api/v4/Patient/Patient1/$validate?mode=create' \
  --header 'Authorization: Basic ****' \
  --header 'Content-Type: application/fhir+json' \
  --data '{
	"resourceType": "Patient",
	"id": "Patient1",
	"meta": {
		"profile": [
			"profile1"
		]
	}
}'

Describe the solution you'd like
When a custom operation is invoked via POST, combine the URL parameters with the Parameters object that we construct from the body.
Instead of any complicated conversion logic, I think we should just append the parameters to the end of the object (in whatever order we get them from the MultivaluedMap queryParameters).

Describe alternatives 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
#3333 should be revisited to confirm whether fhir-client can take advantage of this or not