Fix precompiled gems on aarch64-linux and Ruby 3.0–3.2

[yask123]

Two gaps in the precompiled gems. Both install fine and then fail at require:

• aarch64-linux gems don't load on any Ruby. btls-sys prefixes BoringSSL symbols with a bare objcopy --redefine-syms, and the x86_64 cross image's objcopy exits 0 without rewriting aarch64 archives. The extension then references prefixed symbols that were never defined (104 in 0.6.2's 3.4/wreq_rb.so), so on arm64 you get undefined symbol: build_script_main_SSL_CTX_set_grease_enabled. The pre-script now puts the image's aarch64-linux-gnu-objcopy/-nm first on PATH for that target, cache-version is bumped so the stale BoringSSL build isn't restored, and test-cross-gem also installs the aarch64 gem on an ubuntu-24.04-arm runner.
• No builds for Ruby 3.0–3.2. The platform gems declare >= 2.7, < 3.5.dev but only 2.7, 3.3 and 3.4 are built, so 3.0–3.2 fail with cannot load such file -- .../lib/wreq_rb/wreq_rb. rake-compiler-dock 1.10 already has those cross rubies, and 1.11 still has 3.0.7, so this composes with Add Ruby 4.0 to precompiled gem matrix; drop Ruby 2.7 #2.

Tested locally with rb-sys-dock 0.9.123 and the new pre-script: the aarch64-linux gem (3.0 + 3.4) passes the test suite on Ruby 3.0 / Ubuntu 22.04 arm64 (58 runs, 0 failures) and loads on Ruby 3.4. actionlint is clean.

The root cause is probably better fixed in btls-sys by using the target's objcopy/nm when cross-compiling. Happy to open an issue there. Side note: the rescue LoadError fallback in lib/wreq-rb.rb replaces the real undefined-symbol error with cannot load such file, which is why this was hard to spot.

[yask123]

The Release workflow passes with these changes on my fork, same commit (b68862c): https://github.com/yask123/wreq-rb/actions/runs/36496828045

All four cross-compiles succeed, and test-cross-gem passes on Ruby 2.7, 3.0 and 3.4 for both x86_64-linux and aarch64-linux (the aarch64 jobs on ubuntu-24.04-arm).