GH-50702: [Python] Fix .pyx changes requiring two builds to take effect

[pratyushadk]

Rationale for this change

I noticed while editing a .pyx file that my changes weren't
showing up after a rebuild — I had to build twice. Traced it
to BYPRODUCTS being commented out in UseCython.cmake.

What changes are included in this PR?

I uncommented BYPRODUCTS ${_generated_files} in
cpp/cmake_modules/UseCython.cmake. Without it, CMake doesn't
realize the .cpp was updated in the same build pass, so it
skips recompiling the .so until the next build.

The line was commented out for older CMake compatibility — but
the project requires CMake >= 3.25 now, and BYPRODUCTS has
worked since 3.2, so that's no longer a concern.

Are these changes tested?

This is a build system fix so there's no unit test for it.
The CI builds pyarrow from source and runs the full test suite,
which will validate the build still works correctly.

Are there any user-facing changes?

No — this only improves the dev experience when iterating on
.pyx files. One build instead of two.

• GitHub Issue: [Python] Editing a .pyx requires building extensions twice for the change to take effect #50702

[github-actions]

⚠️ GitHub issue #50702 has been automatically assigned in GitHub to PR creator.

[Copilot]

Pull request overview

This PR fixes incremental rebuild behavior for PyArrow Cython extensions by teaching CMake that the generated C/C++ sources (and related headers) are build byproducts of the Cython custom target, so downstream compilation can re-trigger in the same build pass.

Changes:

• Re-enabled BYPRODUCTS ${_generated_files} on the Cython add_custom_target(...) invocation to ensure build tools (e.g., Ninja) correctly track generated outputs.