Console: number variables will lose precision beyond 18 decimal places

### Version Information

Server Version: 2.3.0

### Environment

OSS

### What is the expected behaviour?

The JSON specification does not specify a precision for numbers.
Therefore, provided the database supports it, we should be able to pass numbers of arbitrary precision as variables,
with no data loss.

### Keywords
12345678901234568
Number precision

### What is the current behaviour?

Any digits beyond the 18th digit is removed from the variables passed in console before the request is sent.

### How to reproduce the issue?

1. Create and track the following table:
```sql
CREATE TABLE number_test (
id INT PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
num NUMERIC(35,25)
);
```
2. Execute the following mutation: this will work as expected
```graphql
mutation {
insert_number_test_one(object: {
test: 0.1234567890123456789012345
}) {
id
test
}
}
```
3. Now execute this mutation that uses variables:
```graphql
mutation ($num: numeric) {
insert_number_test_one(object: {
test: $num
}) {
id
test
}
}
```
```json
{
"num": 0.1234567890123456789012345
}
```
All decimals after the first 18 will be lost before insert.
This can be verified by intercepting the outgoing request in devtools:
```json
{"query":"mutation ($num: numeric) {\n insert_number_test_one(object: {\n test: $num\n }) {\n id\n\t\ttest\n }\n}","variables":{"num":0.12345678901234568}}
```

### Any possible solutions?

Currently this can be worked around by making the variables strings instead.
Please note, this is an issue purely in the console UI, and sending the same request via other http clients does no cause this issue.

If you are encountering this issue in your own code, most likely you are manipulating your numbers in a format that has limited precision, like JavaScript.

### Can you identify the location in the source code where the problem exists?

I have not checked, but my best guess is that variables are being parsed in JavaScript, so numbers are coerced to [IEEE 754](https://en.wikipedia.org/wiki/IEEE_754) Floating point numbers, hence the loss of precision.

### If the bug is confirmed, would you be willing to submit a PR?

I may give this a try.