Accept variables parameter as hash or array in Prometheus proxy API

What does this MR do?

Our Prometheus proxy GET API currently accepts the variables query parameter as an array. Unfortunately, we have observed that the order of elements in the array can be changed by components between the frontend and backend.

In the backend, an array like ['variable1', 'value1', 'variable2', 'value2'] is transformed into a Hash {'variable1' => 'value1', 'variable2' => 'value2'}.

To avoid the problems caused by inconsistent ordering of elements, we are now changing the format of the variables query parameter to a Hash.

This MR changes the Prometheus proxy API to accept the variables parameter in the form of an Array or a Hash. This is the first step to changing the API to accept only a Hash.

The change is being done in multiple steps to avoid a situation where the frontend sends variables in an Array format but the backend accepts variables only as a Hash. A rolling deploy or a canary deploy could result in this situation if the change to the frontend and backend is done in one step.

As @smcgivern mentioned in !33062 (comment 349912349):

This will break on a mixed deployment like GitLab because we have rolling deploys, but also two stages: canary and main. If you get new frontend code, but old backend code, we'll send a hash but expect an array. If you get old frontend code and new backend code, we'll send an array but expect a hash.

Instead, we might need to break this up:

1. A backend-only MR to accept both hashes and arrays.
2. A frontend-only MR to start sending hashes instead of an arrays.
3. A backend-only MR to only accept hashes.

Issue: #219179 (closed)

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team