Reintroduce first-class Google Workspace Domain-Wide Delegation for user subjects in Drive/Sheets/Discovery hooks and operators

### Under which category would you file this issue?

Providers

### Apache Airflow version

We are facing this during a migration from Airflow 2.9 to Airflow 3.x.

### What happened and how to reproduce it?

During this migration, we discovered that delegate_to is no longer available in the Google provider. The changelog indicates that delegate_to was removed and users should use impersonation_chain instead.

However, for Google Workspace use cases such as Google Drive, Google Sheets, and Admin SDK / Discovery API, impersonation_chain is not equivalent to the former delegate_to behavior.

According to the Airflow Google connection docs, impersonation_chain is for service-account impersonation. By contrast, Google auth handles Domain-Wide Delegation for a Workspace user account through delegated credentials with a user subject, for example with_subject("user@company.com").

In an enterprise / company context, especially for Google Drive and Google Sheets, acting on behalf of a real Workspace user is a very common requirement.

Typical examples:

access files owned by or shared with a specific user
preserve the normal Workspace permission model
use Admin SDK operations as a delegated admin user
avoid granting overly broad direct access to service accounts

After the removal of delegate_to, there does not seem to be a first-class way to express this common pattern in Airflow hooks/operators:

authenticate with a DWD-enabled service account
delegate to user@company.com
access user-scoped Google Workspace resources
Why this feels like a regression

This is particularly visible during migration from Airflow 2.9 to 3.x, because existing DAGs that relied on user delegation now need custom code or custom hooks.

Also, the current documentation still mentions Domain-Wide Delegation for Google Workspace-oriented usage, while public hook/operator APIs such as the Sheets hook expose impersonation_chain but not an explicit user-subject parameter. That makes the current support story confusing from a user perspective.

### What you think should happen instead?

Please consider restoring first-class support for Google Workspace user-subject delegation, ideally with a parameter whose meaning is explicit, for example:

subject
delegated_subject
workspace_subject

I am not necessarily asking to restore the old delegate_to name.

A possible direction would be:

keep impersonation_chain for service-account impersonation
add a distinct parameter for Workspace user-subject delegation
internally apply credentials.with_subject(subject) when supported by the underlying credentials
expose this at least on Workspace-oriented hooks/operators such as:
GoogleDiscoveryApiHook
GoogleDriveHook
GSheetsHook
related operators/sensors/transfers

Documentation request:

At minimum, it would help to document more explicitly that:

impersonation_chain = service-account impersonation
Google Workspace Domain-Wide Delegation = delegated user subject
these are different mechanisms and are not interchangeable

If first-class support is intentionally not coming back, it would still be very helpful to provide an officially documented custom-hook pattern for Workspace DWD.

### Operating System

_No response_

### Deployment

Docker-Compose

### Apache Airflow Provider(s)

google

### Versions of Apache Airflow Providers

_No response_

### Official Helm Chart version

Not Applicable

### Kubernetes Version

_No response_

### Helm Chart configuration

_No response_

### Docker Image customizations

_No response_

### Anything else?

There is at least one public discussion that appears to raise the same confusion/regression around the removal of delegate_to, which suggests this is not an isolated migration issue.

Would maintainers be open to a PR adding a dedicated user-subject delegation parameter for Google Workspace-oriented hooks/operators?

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

Read the existing Google provider authentication handling and the GoogleDiscoveryApiHook, GoogleDriveHook, and GSheetsHook entry points first. Define the supported Workspace user-subject behavior across the requested hooks and operators, add coverage for it, and clarify in provider documentation how it differs from impersonation_chain.

Written by the indexing model from the issue text.