Add example of negative integer coercion to ID

[IvanGoncharov]

Changed from:

or integer (such as 4) input value

to

or non-negative integer (such as 0 or 4) input value

[OlegIlyenko]

I would appreciate if you could describe the motivation behind this proposal. I remember raising similar issue in past in a context of an empty string ("") IDs: #404

ATM I have some concerns about this constraint. It is a breaking change and I have a feeling that in might affect some of the API. Also, this limitation (as well as disallowing empty strings) might cause issues integrating with legacy systems (-1 also comes in mind, I have seen API that use such IDs). But also in general, I think IDs should be opaque. I see constraints like this as part of the application domain, so I feel that we should not enforce them in the spec.

[IvanGoncharov]

@OlegIlyenko Looks like negative IDs is a thing:
https://dba.stackexchange.com/questions/2895/what-are-negative-keys-used-for

In this case, I think the specification should have an example of such conversion to show that this is intentional behavior.
I changed PR to:

or integer (such as 4 or -4) input value

[leebyron]

A good next step might be an analysis of what GraphQL libraries already have this restriction in place, to better understand the cost of a breaking change. I believe GraphQL js has had this for a long time and I know many libraries start as a port of that library

[IvanGoncharov]

@leebyron After @OlegIlyenko suggestion I changed this PR to just add example of negative ID value so that it more explicit in the spec.
So no breaking changes in this PR.