GeezerVison

Which issue does this PR close?

• No tracking issue. Pure tooling addition for the release process.

Rationale for this change

The first datafusion-java release will need a changelog written between the previous tag and the release HEAD. The repo currently has no tooling for that, so a release manager would either hand-curate the list of merged PRs or copy a script from a sibling project. `datafusion-comet` already maintains a changelog generator that walks the git range, fetches PRs from the GitHub API, and categorizes them by GitHub label and Conventional Commit prefix. Adopting it here gives us the same output format and keeps future sync with comet mechanical.

What changes are included in this PR?

• `dev/release/generate-changelog.py` — adapted from `datafusion-comet/dev/release/generate-changelog.py`. The only diffs from upstream are the project name (`apache/datafusion-java` in the GitHub API call) and the changelog heading ("DataFusion Java" instead of "DataFusion Comet"). Everything else is identical so subsequent pulls from upstream are simple.
• `dev/release/requirements.txt` — single dependency: `PyGitHub`.

The script categorizes PRs by (in priority order):

Are these changes tested?

Smoke-tested locally against the last three merged PRs (`HEAD~3..HEAD`). The script correctly categorized two `feat:` PRs (#85, #77) as enhancements and one `chore:` PR (#87) as other, and emitted the expected markdown structure (ASF header, intro line with commit/contributor counts, per-bucket sections with author handles, credits block). The `resolve_ref` helper inherited from the upstream correctly normalizes `HEAD` to a SHA before the GitHub API call, so refs that resolve differently locally vs. on the default branch don't drift.

`python3 -c "import ast; ast.parse(open('dev/release/generate-changelog.py').read())"` is the syntactic check; the end-to-end test above covers the semantic behaviour.

Are there any user-facing changes?

No. Release-manager-facing tooling only.