Formalize Global Object Identification.

### Preface
The [Global Object Identification](https://graphql.org/learn/global-object-identification) introduces
a "best practice" for a GraphQL server implementation.

**The problem is that it is not very strict and it makes hard to write codegen-clients that
assume the server comply with these specifications.**

### Examples

*The following are the major spec-lacks I encountered while trying to build a client code-gen.*

- **It is not clear what [field stability](https://graphql.org/learn/global-object-identification/#field-stability) says about lists / union / interface**
> If a field is queried on both objects, the result of querying that field on the first object must be equal to the result of querying that field on the second object.
> - If the field returns a scalar, equality is defined as is appropriate for that scalar.
> - If the field returns an enum, equality is defined as both fields returning the same enum value.
> - If the field returns an object, equality is defined recursively as per the above.

- **It is not clear whether field stability should consider field arguments as well.**
Although it is kind of implied by the [Plural identifying root fields](https://graphql.org/learn/global-object-identification/#plural-identifying-root-fields) (even though they does not implement `Node`) section it is not a strict requirement.

> NOTE Spec-compliant servers may expose root fields that are not plural identifying root fields; the spec-compliant client will just be unable to use those fields as root fields in its queries.

This basically means I have nothing to do with it (automatic wise...)
Note that AFAIK relay-graphql caches fields by arguments.

### Suggestion

Create a more strict version of [Global Object Identification](https://graphql.org/learn/global-object-identification) spec so that
client libraries won't need to have their own servers requirements or wrong assumptions.