Console data edit/insert issue when dealing with big numbers

### Version Information

Server Version: <= 2.17.0
CLI Version (for CLI related issue): 2.17.0

### Environment

Cloud / OSS / EE

### What is the current behaviour?

If you have the numeric value saved in postgres table like numeric(78,0) most likely in cases where you want to capture uint256 value, ERC20 token value etc, etc... and turn on the flag HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES="true" Hasura console will not be aware of this and when you open tab "edit" > change the value it will lose precision because parseFloat is being used on the string value from input.


### What is the expected behaviour?

Stringify certain Postgres numeric types, specifically bigint ,numeric ,decimal and double precision as they don't fit into the IEEE-754 spec for JSON encoding-decoding.

Because HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES is set to true, the value should be sent as string to the GraphQL, if I do this manually by updating request, it works. So the server is working as expected, issue is in the UI.

### How to reproduce the issue?

1. Create postgres table with type numeric(78,0)
2. Open the Hasura Console
3. Go to Data > select table containing numeric column > Edit a specific row
4. Change numeric column to something big
5. Save

### Any possible solutions/workarounds you're aware of?

There are two solutions I see, either we introduce a way to explicitly send different type to the API, ignoring the type of the column, example if the number is wrapped in quotes ("" or '') the component will not use parseInt or parseFloat but leave it as is. (It also seems that similar transformation is already being done with booleans "true": string -> true: boolean, which I could also fix in the PR because "True", "tRuE" or "1" would not be sent as true :) ...).

The second solution would be checking the state of the server finding the state of HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES flag maybe through "/v1alpha1/config" and then send strings if it is active.

I'm looking for feedback on possible solutions, and I'm fine with creating PR for the first solution.

### Keywords

IEEE-754, bigint, BigNumber, HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES, --stringify-numeric-types

Start with the Hasura Console Data table row edit flow described in the reproduction steps, using a PostgreSQL numeric(78,0) column and HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES enabled. Trace the value from the edit input through the save request and verify that large numeric values retain their precision and are sent as strings, then repeat the edit-and-save reproduction to confirm the fix.

Written by the indexing model from the issue text.