Fix V8 upgrade CI regressions across Android/Linux/Darwin

[mjackson]

Summary

This PR includes all build-fix commits needed for the V8 14.5.x upgrade path:

• Remove patches/20250331-stringhasher-arm64.patch because the fix is already upstream in V8 and the patch now fails as reversed/already-applied.
• Disable Clang/libc++ module builds and allocator shim in deps/build.py to avoid libc++/visibility breakages.
• Force --clang for Linux matrix builds in .github/workflows/v8build.yml (current V8 revisions fail with GCC in CI).
• Force Chromium bundled libc++ for Android builds (use_custom_libcxx=true) so std::atomic_ref is available.
• Improve Actions cache correctness by:
  • caching deps/.build/<os>_<arch>, and
  • keying on needs.build_common.outputs.v8_hash plus build-script/patch fingerprints.

Why

Recent V8 upgrade workflow runs have failed with:

• Android: no member named 'atomic_ref' in namespace 'std'
• Linux (GCC): compile failures after upstream changes
• Darwin: allocator-shim/libc++ visibility conflicts
• Patch step: obsolete ARM64 string-hasher patch failing as reversed/already-applied

[tommie]

Hi. Thanks for the PR!

I've been working on this in https://github.com/tommie/v8go/tree/issue-109, but haven't been able to get all platforms to run cleanly so far. Here's the latest build with Darwin failing, but Linux succeeding.

Does the Android tests run cleanly? I had an issue with customcxx causing symbol mangling mismatch, so when the cgo files were compiled with system libc++, they wouldn't find any function that used e.g. std::optional in arguments. E.g. v8::JSON::Parse. I also wouldn't want to carry a custom libc++ in the repo, so I'm not sure this is the way forward. Thoughts on that?

Could you explain the "Disable Clang/libc++ module builds" a bit? What errors were you seeing with module builds?