Feature Request: Config Flag to Enable ID Input Coercion

Section 3.5.5 of the GraphQL spec describes the ID type, and includes following subsection:

> ### Input Coercion
>
> When expected as an input type, any string (such as `"4"`) or integer (such as `4` or `-4`) input value should be coerced to ID as appropriate for the ID formats a given GraphQL service expects. Any other input value, including float input values (such as `4.0`), must raise a _[request error](https://spec.graphql.org/draft/#request-error)_ indicating an incorrect type.
>
> [Source](https://spec.graphql.org/draft/#sel-FAHXZHEBAAADDKe5jD)

In short: compliant servers _should_ accept a `String` or `Int` for `ID`-type inputs, but it's not required. Unfortunately, Relay has no way to know that a server supports that coercion, so it's forced to limit `ID` inputs to strings. That's an issue mostly in Flow/TypeScript typings and in the LSP, since Int `ID`s are disallowed. Clients are then forced to manually stringify `Number` input IDs at runtime to satisfy that restriction, even though the (generally faster) server supports that cast.

Is there any interest in allowing Relay users to declare server-side support for ID input coercion? I imagine it'd be configurable via a `server_supports_id_input_coercion` flag (or similar) and default to "off" for safety. It'd be a moderate ergonomics boost for systems that return IDs in `Int`-typed fields.

Start by locating Relay's Flow/TypeScript ID input typings and LSP validation, then trace how server configuration options are declared and propagated. Done means an opt-in server_supports_id_input_coercion setting permits integer ID inputs in those surfaces while the default remains string-only, with coverage for both modes.

Written by the indexing model from the issue text.