bigquery: Support specifying access token on every API call

## Is your feature request related to a problem? Please describe.
The current Google Cloud Go client library for BigQuery (cloud.google.com/go/bigquery) only supports specifying credentials (like an OAuth2 access token) during the initial client creation. This poses a significant challenge for multi-tenant applications or services that act as a proxy for multiple users.

Our project, the MCP Toolbox, is a server that executes tool calls on behalf of various end-users. Each incoming request may be authenticated with a different user's access token. The current SDK design forces us to create a new bigquery.Client for every single API call to use the correct user's credentials. This approach is inefficient, introducing substantial performance overhead from repeated client setup.

## Describe the solution you'd like
We propose enhancing the BigQuery client library to support per-request credentials. This would allow an application to use a single, long-lived bigquery.Client instance and specify a different access token for each individual API call.

The ideal API would involve passing a CallOption, similar to how other options like headers are handled. For example, methods like Query.Read, Table.Inserter.Put, Dataset.Create, etc., could accept an option.WithTokenSource to override the client-level credentials for that specific operation.

An example of how this could be used:
```
func handleUserRequest(ctx context.Context, client *bigquery.Client, userQuery string, accessToken string) {
// Execute the query using the user's token
q := client.Query(userQuery, accessToken)
it, err := q.Read(ctx)
if err != nil {
// Handle error
}
// ... process results
}
```

## Describe alternatives you've considered
Our current alternative is implementing a caching and pooling mechanism for *bigquery.Client instances, keyed by user tokens. This solution requires us to manage client lifecycles, token expirations, and cache eviction. This feels like re-implementing connection management that could be handled more effectively within the SDK itself.

## Additional context
This feature is critical for the growing number of applications built as centralized agents that need to execute Google Cloud operations on behalf of many different users.