Fix bundler 4.x incompatibility caused by rubygems 4.x update

[tnikolova82]

Summary

This PR fixes two issues blocking the CF integration tests with cflinuxfs4 + cflinuxfs5:

1. Bundler 4.x incompatibility (Bug 5)

Rubygems 4.0.9 ships bundler 4.x as a default gem. When UpdateRubygems() runs
ruby setup.rb, it installs bundler 4.0.9 which overwrites the buildpack's bundler 2.7.2.

Changes:

• src/ruby/versions/ruby.go — Updated GetBundlerVersion() regex to handle both
  Bundler version X.Y.Z (bundler 2.x) and X.Y.Z (date hash) (bundler 4.x) formats
• supply/supply.go UpdateRubygems() — Re-install bundler 2.x after rubygems update
  when rubygems major version >= 4
• supply/supply.go InstallBundler() — Fixed version selection: bundler 1.x uses
  "1.x.x" dependency, everything else uses "2.x.x"
• supply/supply.go VendorBundlePath() — Only bundler 1.x uses nested vendor path
• supply/supply.go InstallGems() — Bundler removal applies to bundler 2+
• Added tests for bundler 2.x BUNDLED WITH, bundler 4.x vendor_bundle, and
  rubygems 4.x re-install scenarios

2. Switchblade multi-stack buildpack deletion (Bug 8)

When CF has both cflinuxfs4 and cflinuxfs5 stacks deployed, multiple buildpacks share
the same name (e.g., ruby_buildpack for each stack). The switchblade Initialize()
method called cf delete-buildpack -f <name> without -s <stack>, which fails with:

Multiple buildpacks named ruby_buildpack found. Specify a stack name by using a '-s' flag.

Changes:

• vendor/.../switchblade/internal/cloudfoundry/initialize.go — Parse stack field
  from /v3/buildpacks API response and iterate over all resources, deleting each
  with the appropriate -s <stack> flag. Handles null-stack buildpacks by omitting
  the -s flag when stack is empty.

This is a vendored fix; the upstream switchblade repo (v0.9.4) has the same bug.