feat(compiler): Add SchemaCoordinate::lookup methods

[goto-bus-stop]

All the coordinate types have a .lookup(&schema) method.

I omitted the SchemaLookup trait that used to be in #757. It was only there to support schema.lookup(&coord), but that's exactly the same as writing coord.lookup(&schema), and it's simpler not to have both.

assert!(coord!(ObjectDefault.someField(privateArg:)).lookup(&schema).is_ok());
// vs.
assert!(schema.type_field("ObjectDefault", "someField").is_some_and(|f| f.arguments.iter().any(|arg| arg.name == "privateArg")));

Type attribute coordinate syntax can refer to object or interface field definitions, input
field definitions, and enum values. TypeAttributeCoordinate::lookup returns an enum to
account for those possibilities. To look up a specific kind of type attribute, there are
convenience methods:

• TypeAttributeCoordinate::lookup_field for object or interface fields
• TypeAttributeCoordinate::lookup_input_field for input fields
• TypeAttributeCoordinate::lookup_enum_value for enum values

This should help with writing assertions in tests where you normally already know what
type you expect.

[SimonSapin]

I think having lookup_field / lookup_input_field / lookup_enum_value is a great idea. I’m less convinced about introducing two enums just for TypeAttributeCoordinate::lookup and SchemaCoordinate::lookup to exist. I struggle to imagine a use case where you don’t know in advance what kind of item you want to look up. But having them doesn’t "cost" all that much.

[goto-bus-stop]

It's a fair point. I think SchemaCoordinate::lookup has a use case in developer tooling where you could get a schema coordinate from user input, while TypeAttributeCoordinate::lookup really just exists for completeness (but it's pretty much free as lookup_ref would still exist to support SchemaCoordinate::lookup).