[CI] Drop x86_64 macOS from JNI builds

[jbonofre]

Describe the enhancement requested

Homebrew treats x86_64 macOS as a tier 3 configuration and rarely builds bottles for it. This has broken the JNI macos-15-intel x86_64 job in the RC workflow repeatedly, because brew bundle doesn't build from source and aborts with no bottle available! before anything is compiled:

• MINOR: Don't install Homebrew's aws-sdk-cpp and gRPC for JNI macOS build #1269 worked around it for aws-sdk-cpp and gRPC.
• MINOR: Don't install Homebrew's Node.js for JNI macOS build #1270 worked around it for Node.js.

Each of these was a formula-by-formula patch, and any new dependency added to apache/arrow's cpp/Brewfile can break the job again the same way. We can't keep an x86_64 macOS JNI build green on a configuration Homebrew doesn't support.

As noted in #1269, dropping the macos-15-intel entry needs its own discussion because it is user-facing, so this issue is that discussion.

Proposal

Drop x86_64 macOS from CI:

• rc.yml: remove the macos-15-intel / x86_64 entry from the jni-macos matrix, and stop extracting and verifying jni-macos-x86_64.tar.gz in the binaries job.
• test.yml: remove the AMD64 / macos-15-intel entry from the macos test matrix.
• Remove the Homebrew workarounds that only existed for the x86_64 runners (the /usr/local python@XXX --overwrite conflict loop, and the uname -m guard around the pkg-config uninstall).

User-facing impact

Release JARs would no longer bundle x86_64 macOS .dylib files for arrow_cdata_jni, arrow_dataset_jni, arrow_orc_jni and gandiva_jni. Intel Mac users of those modules would need to build the JNI libraries themselves. ci/scripts/jni_macos_build.sh still handles x86_64, so a local Intel build keeps working.

aarch64 macOS, x86_64 and aarch64 Linux, and x86_64 Windows are unaffected.

Component(s)

Java, CI