Automatic Delegation of Nested Field Resolvers to Root Query Resolvers

# Feature Request: Automatic Delegation of Nested Field Resolvers to Root Query Resolvers

## Description

Currently, when defining a nested field (e.g., the `creator` field in a type like `EstablishmentType`), you must explicitly specify a resolver for that field—even if a resolver for the same field is already defined in the root query. This forces developers to duplicate logic or centralize it in helper functions to maintain consistency.

## Current Behavior

- Each nested field is resolved independently using its own resolver (or the default resolver, which simply looks up the corresponding property on the source object).
- There is no built-in mechanism that automatically delegates the resolution of a nested field (e.g., `creator` in `EstablishmentType`) to the resolver defined in the root query for that field.

## Expected Behavior

- The library should automatically recognize, based on the field name, that if a resolver for `creator` is defined in the root query, it should be invoked automatically when resolving the nested `creator` field in other types.
- This behavior would eliminate the need to manually specify the same resolver logic in multiple places, reducing duplication and ensuring consistency.

## Proposed Implementation

- **Global Configuration Option:** Introduce a configuration flag in the library that enables automatic delegation of nested field resolvers to their corresponding root query resolvers.
- **Resolver Mapping:** When resolving a nested field, the library could look up a global mapping of resolvers (populated from the root query) and, if a matching resolver exists, delegate the resolution to it instead of using the default behavior.
- **Override Capability:** Allow this behavior to be overridden by explicitly defining a custom resolver on a nested field when necessary.

## Example

Assume you have the following root query resolver for `creator`:

```go
"creator": &graphql.Field{
Type: UserType,
Args: graphql.FieldConfigArgument{
"id": &graphql.ArgumentConfig{Type: graphql.NewNonNull(graphql.ID)},
},
Resolve: func(p graphql.ResolveParams) (interface{}, error) {
// Logic to retrieve the user by their ID.
},
},
```

# 2. Nested Field in EstablishmentType
Now, consider an EstablishmentType that has a nested creator field. With the proposed feature, you would define the type without specifying an explicit resolver for creator:

```go
var EstablishmentType = graphql.NewObject(graphql.ObjectConfig{
Name: "Establishment",
Fields: graphql.Fields{
"id": &graphql.Field{
Type: graphql.ID,
},
"name": &graphql.Field{
Type: graphql.String,
},
"creator": &graphql.Field{
Type: UserType,
// No resolver is specified here; we expect the system to automatically delegate
// to the root query's "creator" resolver.
},
},
})
```

# 3. Expected Query Behavior
When a query like the following is executed:

```
graphql
{
establishment(id: "1") {
id
name
creator {
id
email
}
}
}