Honor `BUNDLE_LOCKFILE` (added in Bundler 4) when selecting the lockfile used
for Bundler version detection, deployment mode, and bundler-cache keys. Without
this, workflows using an alternate lockfile can read the wrong `BUNDLED WITH`
version and generate cache keys from the wrong lockfile.
* JRuby 9.2.x has been EOL for a very long time, so there's no value in telling people to use a newer version.
* https://github.com/jruby/jruby/issues/7106 was resolved with JRuby 9.4.0.0. All prior versions are EOL.
* https://github.com/jruby/jruby/issues/7182 was determined to be a JDK issue and no longer occurs with more recent builds.
**What does this PR do?**
This PR provides the final piece of the puzzle to fix#682: now that
ruby-dev-builder is building `3.4-asan` Rubies since
https://github.com/ruby/ruby-dev-builder/pull/15, we can make them
available for use.
**Motivation:**
At Datadog, we're using ASan builds to check for issues
[in our library](https://github.com/datadog/dd-trace-rb),
and having a `3.4-asan` build improves the experience of having
these checks be a required CI step. Using the ASan builds built from
ruby-head means our CI could break because of unrelated issues/changes
from ruby-head.
**Additional Notes:**
`yarn` was trying really hard to update a bunch of things, which
generated A LOT of diff noise. I've manually pared them down just
to the actual changes related to adding the new variant so the
diff makes a bit more sense.
**How to test the change?**
I've already tested this in
https://github.com/DataDog/dd-trace-rb/actions/runs/13392865620/job/37696781848
and it seems to be working fine!
Benoit Daloze