feat(biome_graphql_parser): parse object extension

[vohoanglong0107]

Summary

Parse GraphQL object type extensions (link). This is a small case, as almost all parsing logic was handled by a previous PR focusing on parsing object type definition.
The object extension syntax defined in the ungrammar was also needlessly complicated, so this PR also simplifies the syntax.

Test Plan

All tests should pass

[codspeed-hq]

CodSpeed Performance Report

Merging #2928 will not alter performance

_{Comparing vohoanglong0107:feat-graphql-parse-object-type-extension (61744b6) with main (8f3c811)}

Summary

✅ 92 untouched benchmarks

[ematipico]

PR has conflicts

[denbezrukov]

bump can panic if the current token doesn't match.
It's better to use expect or have a guard like is_at_object_type_extension

[vohoanglong0107]

I have placed a check on the outer parse_extension function here, so unless this function was called outside of parse_extension it should be fine. I think panic would even be preferred in this case, cause it will fail the test and indicate that this function was called at a unintended location. What do you think?

[denbezrukov]

Hmm, I'm unsure how to handle this better because I understand the cons and pros of both approaches.
I see two ways:

1. Add is_at_object_type_extension and use it only in parse_object_type_extension. This brings some duplication because we already check the correct parser state beforehand. However, I tend to use this approach.

2. Write documentation stating that we must check extends and type on the call sites; otherwise, it can cause a panic.

[vohoanglong0107]

I have added documents to check for the tokens. Since this pattern is also used in some other places, I have also documented them as well.