support `access_token` when using `workload_identity_provider` without `service_account`

TL;DR

Today, this usage

      - uses: 'google-github-actions/auth@v3'
        id: 'hopefully-emit-access-token'
        with:
          workload_identity_provider: 'projects/.../locations/global/workloadIdentityPools/.../providers/...' # values masked
          token_format: 'access_token'

fails with

the GitHub Action workflow must specify a "service_account" to use when generating an OAuth 2.0 Access Token.

It is entirely possible to generate an access token for the direct workload identity principal via some extra hops (see below). It would be nice if this was simplified to "just work".

This is the workaround today:

      - uses: 'google-github-actions/auth@v3'
        with:
          workload_identity_provider: 'projects/.../locations/global/workloadIdentityPools/.../providers/...' # values masked
      - uses: 'google-github-actions/setup-gcloud@v3'
      - name: 'emit access token'
        id: 'emit-access-token'
        run: |
          token="$(gcloud auth print-access-token)"
          echo "::add-mask::$token"
          echo "access-token=$token" >> "$GITHUB_OUTPUT"

... and ${{ steps.emit-access-token.outputs.access-token }} is available for all later steps in the job.

Detailed design

See above.

Additional information

N/A

Start by tracing the auth action's handling of token_format: access_token when only workload_identity_provider is supplied. Compare that path with the documented gcloud auth print-access-token workaround. Done means the action directly produces an access token for the workload identity principal without requiring service_account, while preserving the later-step output behavior.