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 …