Feature request: add --impersonate-service-account flag for keyless per-mount identity

**Is your feature request related to a problem? Please describe.**

When mounting multiple GCS buckets with different service account identities (e.g. for per-bucket access isolation), gcsfuse currently requires persistent SA key files via `--key-file`. There's no way to specify service account impersonation at mount time using short-lived, automatically-refreshed credentials.

The desired fstab configuration would look like:

```
bucket-a /mnt/bucket-a gcsfuse rw,_netdev,impersonate_service_account=sa-a@project.iam.gserviceaccount.com
bucket-b /mnt/bucket-b gcsfuse rw,_netdev,impersonate_service_account=sa-b@project.iam.gserviceaccount.com
```

This is not possible today without key files.

**Describe the solution you'd like**

A new `--impersonate-service-account` flag (and corresponding `impersonate_service_account` fstab option) that:

1. Takes a service account email as its value
2. Uses the ambient credentials (VM default SA, ADC, etc.) to obtain short-lived tokens for the target SA via the IAM Credentials API
3. Auto-refreshes tokens as they expire — no manual token management, no mount interruption

The Go ecosystem already supports this pattern cleanly. The `google.golang.org/api/impersonate` package provides a `TokenSource` that handles the full credential chain and auto-refresh transparently. Since gcsfuse is written in Go and already uses the Cloud Storage Go client, this would wire in naturally as an additional `option.WithTokenSource(...)` path in the credential setup logic.

The required IAM permission is `roles/iam.serviceAccountTokenCreator` on the target SA, granted to the caller's identity — a standard, auditable IAM binding with no persistent secrets.

**Describe alternatives you've considered**

- **`--key-file` per mount**: Works, but persistent SA keys are a security risk and an operational burden to rotate.
- **Pre-generating ADC impersonation files**: Possible since #647 was resolved in v0.40, but the `impersonated_service_account` credential type in the ADC file still carries an `expiry` — making long-lived mounts fragile without an external token-refresh daemon.
- **Wrapper scripts with `gcloud auth print-access-token --impersonate-service-account`**: Access tokens expire (1 hour default) and break the mount; not suitable for persistent mounts.
- **`--token-url`**: Could be used with a local token server, but requires a separate process per SA and adds significant complexity.

**Additional context**

The `gcloud` CLI has supported `--impersonate-service-account` since 2020, and other Google Cloud OSS tools have since added the flag for the same reasons (e.g. [cloud-sql-proxy #417](https://github.com/GoogleCloudPlatform/cloud-sql-proxy/issues/417)). This would bring gcsfuse to parity for teams that follow a keyless security posture.

The use case is particularly common on GCE VMs where the VM's attached SA has `Token Creator` on multiple target SAs, and each mount point should operate with least-privilege access to its respective bucket.