Schema coordinates

[magicmark]

@benjie @leebyron This PR implements the changes on top of the existing schema-coordinates branch as discussed in July's WG meeting:

https://github.com/graphql/graphql-wg/blob/main/notes/2025/2025-07.md#schema-coordinates

Specifically:

• introduces a new SchemaCoordinateLexer class inside src/language/schemaCoordinateLexer
• imports and reuses the existing {createToken, printCodePointAt, readName} helpers
• creates a new LexerInterface interface to allow the helpers to accept either instance of a Lexer without copy/pasting.

What I dislike about this PR:

• continues to "infect" the rest of parser.ts with the knowledge/existence of schema coordinates (LexerInterface)
• does not meet the "this is it's own thing and tree-shakable" dream as discussed in the meeting

What I like about this PR:

• seems like the minimal diff required to do this "properly" (including locations, useful error messages)

tl;dr if we tried to completely devolve Parser of responsibility of schema coordinates, and started on a minimal implementation of parseSchemaCoordinate() that advances a lexer instance token by token, we'd end up at something very similar to Parser.... I did try a few versions of this and copy and pasting things but this ended up being neater overall.

FWIW I did start to a attempt a minimal parseSchemaCoordinate() function here: https://github.com/magicmark/graphql-js/blob/586b7174dc730fef47368ce4fbc385fb1f733360/src/language/schemaCoordinate.ts#L44

but it turns out that doing it imperatively and correctly without a nice lexer/parser is kinda hard! the more logic I add to this, the closer I get to essentially recreating a lexer/parser... which we already have :)

wdyt? should we keep trying for more of a middle ground here?

[JoviDeCroock]

does not meet the "this is it's own thing and tree-shakable" dream as discussed in the meeting

My two cents on this is that we already have quite a bloated idea of a parser/lexer, in an ideal world we would split up the parser to be the Definition- and Execution Language. Which would help clients tree-shake down to a minimal visit, print and parse implementation rather than what we have now.

Example:

• https://bundlejs.com/?q=graphql&treeshake=%5B%7B+print%2Cparse%2Cvisit+%7D%5D --> 10.5kb gzip
• https://bundlejs.com/?q=%400no-co%2Fgraphql.web&treeshake=%5B%7B+print%2Cparse%2Cvisit+%7D%5D --> 3.1kb gzip

This mostly to say that to push a spec forward I wouldn't really be bothered too much about the increase in bundle-size/lack of tree-shaking. For clients we are already massively overweight as we deliver SDL regardless of your needs.

In the ideal world scenario the coordinates parser could be tied to the SDL lexer which would exempt clients from importing this by default.