`glab api graphql` does not support complex variable types
<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label:
- https://gitlab.com/gitlab-org/cli/-/issues/?label_name%5B%5D=type%3A%3Abug
and verify the issue you're about to submit isn't a duplicate.
--->
### Checklist
<!-- Please test the latest versions, that will remove the possibility that you see a bug that is fixed in a newer version. -->
- [x] I'm using the latest version of the extension (Run `glab --version`)
- Extension version: v1.36.1-0.20240222160154-6ac665d5891e
- [x] Operating system and version: openSUSE Tumbleweed 20240207
- [x] Gitlab.com or self-managed instance? Both
- [x] GitLab version (if self-managed) 16.8.1
(Use the `version` endpoint, like this: gitlab.my-company.com/api/v4/version)
- [x] I have performed `glab auth status` to check for authentication issues
### Summary
<!-- Summarize the bug encountered concisely -->
`glab api graphql` does not support complex variables. For example:
```shell
glab api graphql \
-f query='mutation($input: UpdateIssueInput!){updateIssue(input: $input){errors issue{id state title}}}' \
-f input='{"iid":"16", "projectPath":"bmendric/nvim-config", "stateEvent":"CLOSE"}'
```
### Environment
<!--
on POSIX system (Linux, MacOS), run
bash -c 'printf -- "- OS: %s\n- SHELL: %s\n- TERM: %s\n- GLAB: %s" "$(uname -srm)" "$SHELL" "$TERM" "$(glab --version)"'
and replace the following section with the result.
If you use non-POSIX system, fill in the section manually:
- OS: Your operating system including version and architecture (Windows 11 - AMD64, MacOS Sonoma - ARM64)
- SHELL: Your shell (bash, fish, zsh, ...)
- TERM: Your terminal emulator (Kitty, Xterm2..)
- GLAB: result of running `glab --version` (glab version 1.32.0 (2023-08-18))
-->
- OS: Linux 6.7.4-1-default x86_64
- SHELL: /bin/bash
- TERM: screen-256color
- GLAB: glab version DEV
<!--
Please include any other information that you believe might be relevant
in debugging. For example, you may include a shell framework like oh-my-zsh
or other customizations like editing the prompt (PS1, PS2, and others).
-->
Other:
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Attempt to do a graphql mutation with the CLI that requires complex (i.e. a JSON object) variables. For example:
```shell
glab api graphql \
-f query='mutation($input: UpdateIssueInput!){updateIssue(input: $input){errors issue{id state title}}}' \
-f input='{"iid":"16", "projectPath":"bmendric/nvim-config", "stateEvent":"CLOSE"}'
```
### What is the current _bug_ behavior?
<!-- What actually happens -->
Running the above query results in:
```json
glab: Variable $input of type UpdateIssueInput! was provided invalid value
{
"errors": [
{
"message": "Variable $input of type UpdateIssueInput! was provided invalid value",
"locations": [
{
"line": 1,
"column": 10
}
],
"extensions": {
"value": "{\"iid\":\"16\", \"projectPath\":\"bmendric/nvim-config\", \"stateEvent\":\"CLOSE\"}",
"problems": [
{
"path": [],
"explanation": "Expected \"{\\\"iid\\\":\\\"16\\\", \\\"projectPath\\\":\\\"bmendric/nvim-config\\\", \\\"stateEvent\\\":\\\"CLOSE\\\"}\" to be a key-value object."
}
]
}
}
]
}
```
In other words, the variable is being treated as an encoded string rather than being passed directly through. The result is valid, but incorrectly formatted, JSON that GitLab's graphql correctly rejects.
### What is the expected _correct_ behavior?
<!-- What you should see instead -->
glab should have some way to supply more complex data structure to the graphql api request such that the above request is possible.
### Relevant logs and/or screenshots
<!--- Paste the activity log from your command line -->
N/a
### Possible fixes
<!-- If you can, link to the line of code that might be responsible for the problem -->
https://gitlab.com/gitlab-org/cli/-/blob/main/commands/api/http.go?ref_type=heads#L60 -- There is some parsing that glab is already doing to, apparently, deal with array objects. In theory, it would be possible to write some regex to do similar things to the array handling, however, this feels like the incorrect approach.
Rather, I would expect `--raw-field` parameters to generally be treated as `json.RawMessage` objects so they are passed directly through to the request. Since this is a bit niche, here's an example https://go.dev/play/p/vargAvVKPZV
issue