Remove passing the GH_PERSONAL_ACCESS_TOKEN to actions/checkout

[ThoSap]

The CI for PR #55 fails because we pass the GH_PERSONAL_ACCESS_TOKEN to actions/checkout.

It fails because the pull request is opened from a community fork.
In GitHub Actions, secrets (like GH_PERSONAL_ACCESS_TOKEN) are not exposed to workflows triggered by pull requests from external forks for security reasons.

Because the secret is not available in the fork PR context, the expression evaluates to an empty string. The actions/checkout action sees the token parameter provided but empty, which causes the Error: Input required and not supplied: token error.

The action actions/checkout uses the default github.token automatically if we omit the token parameter.

I'll fix it for the test.yml workflow for now, but not the release.yml workflow, as this is a different topic, as the release.yml workflow also pushes a commit (change the version in the README.md) back to the repo, which also triggers the CI again, as we use the GH_PERSONAL_ACCESS_TOKEN there.
Omitting the token or using GITHUB_TOKEN or github.token would not trigger other workflows (which could be what we want).

---

I checked how other open-source dependencies we use in this project do it, and they all omit passing any token, so the default github.token is used.

https://github.com/google/error-prone/blob/960e04b8c6269512bab29bc7eac1fa6669961d1a/.github/workflows/ci.yml#L53-L54

https://github.com/uber/NullAway/blob/9b04703048af3f13e749a43fbf494834cda6ecd7/.github/workflows/continuous-integration.yml#L22-L23

https://github.com/assertj/assertj/blob/82886e8da929e9bbee275b9c4249883f18f1e7f0/.github/workflows/main.yml#L28

https://github.com/ongres/scram/blob/5fdd1016549a84a5f38ac453c271b8393fc75936/.github/workflows/maven.yml#L19

https://github.com/pgjdbc/pgjdbc/blob/1276a3decb6e05c8e836498a44b88658a4fbf46a/.github/workflows/main.yml#L43-L45

https://github.com/projectlombok/lombok/blob/c8f91b529497dfde33a72eef69a361d8bfbbd41d/.github/workflows/ant.yml#L13

https://github.com/tbroyer/gradle-errorprone-plugin/blob/e56fce6bbafc18c8a4c25fcceafdbe9712cb56e6/.github/workflows/gradle.yaml#L17

[stplasim]

Good fix, this is a real attack vector. Worth noting we have a similar situation with GRADLE_ENCRYPTION_KEY: it'll be empty on fork PRs, but the Gradle action handles that gracefully and just skips the configuration cache. Builds will still work, just a touch slower. Should be fine.

[ThoSap]

Worth noting we have a similar situation with GRADLE_ENCRYPTION_KEY: it'll be empty on fork PRs, but the Gradle action handles that gracefully and just skips the configuration cache. Builds will still work, just a touch slower. Should be fine.

Good point!