Version bump bundler itself and dev dependencies

[mjankowski]

Opening this JUST in -custom for starters, but if there's general head nodding here I'll open analagous PRs in the other repos.

General motivation here is to bump things sufficiently to get rid of various gem/dep warnings about ruby 3.5 changes. In this PR I bumped everything except any standard- or rubocop- related gems.

[mjankowski]

Separately, some project meta questions...

• I noticed that within the .standard.yml for the various gems, the main standard gem has a ruby_version of 3.0, whereas -rails has 2.7 and -performance and -custom have 2.6 ... but all of them are aligned in their gemspec to >= 3.0 ... should these be aligned in their settings? (not sure if anything will need changing, just curious on consistency)
• I know we previously bumped the min ruby version to 3.0 across all gems. Any thoughts on if/when to:
  • Drop 3.0 support? (EOL for ~6 months now)
  • Drop 3.1 support? (will be EOL in the spring)
  • Add 3.4 preview to CI matrix? (will presumably be released arond EOY)

Happy to do some of the PRs around these various ideas, just want to make sure there's vague direction established first.

[searls]

IMO we should probably have a RUBY_UPGRADE.md file with a checklist that we follow each time a Ruby is EOL'd.

Imagining something like:

• Update gemspec to lowest supported Ruby version
• Update CI YAML in all official gems to include latest Ruby and remove EOL'd version
• Update .standard.yml in all official gems to lowest supported Ruby version

[mjankowski]

Agreed ... checklist like that or even just a version/maintenance/policy/etc type page (or README section) which laid out high level intentions re: version support and bumps and which things should change at each bump would be nice. Happy to take a crack at after we work through what that schedule actually is.

For now - I'll do a pass to at least align the standard yml ruby version in each gem (I think there will be minimal code changes) to the already lowest 3.0. Will link those PRs back here.

RE: ruby version policy ... I believe this spring when we bumped to 3.0 minimum it was already EOL, but it felt excessive to drop a bunch of versions at a time so we left it there. Thoughts on when we SHOULD drop that? And then ... future speculative thoughts on what a schedule for 3.1 should look like?

[searls]

IME, I see no benefit in dropping versions the instant they go EOL. Tons of users spend years and years on EOL versions and cutting them off from Standard for no other reason than because it's unsupported by Ruby core would have little effect apart from reducing Standard usage. At the same time, establishing a cadence is important to being maintainable. IMO, policy would be to drop EOL minus 1 or to drop the most recently EOL'd version (which happens in the spring) only when the next release hits (on Christmas).  Feel free to draft a doc like described as part of this PR and enumerate the official gems that should be included