https://github.com/ruby/rubygems/commit/79ba4a537d

https://github.com/rubygems/rubygems/commit/e1b8bdcede

This is not currently causing any issues, but I think the most correct
thing to do is that Bundler loads the extensions to RubyGems in the
first place, so that they are available from the beginning.

https://github.com/rubygems/rubygems/commit/88faa5c7bb

We have a quality spec that parses all code for explicit usages of
`Bundler.settings[<something>`, to detect undocumented settings. So
using `Bundler.settings` consistently will help catching these things.

https://github.com/rubygems/rubygems/commit/ce01bb7cc5

Overriding the version constant feels too magic and creates a set of
problems. For example, Bundler will lock the simulated version, and that
can cause issues when the lockfile is used under an environment not
simulating Bundler 4 (it will try to auto-install and auto-switch to a
version that does not exist).

On top of that, it can only be configured with an ENV variable which is
not too flexible.

This commit takes a different approach of using a setting, which is
configurable through ENV or `bundle config`, and pass the simulated
version to `Bundler::FeatureFlag`. The real version is still the one set
by `VERSION`, but anything that `Bundler::FeatureFlag` controls will use
the logic of the "simulated version".

In particular, all feature flags and deprecation messages will respect
the simulated version, and this is exactly the set of functionality that
we want users to be able to easily try before releasing it.

https://github.com/rubygems/rubygems/commit/8129402193

https://github.com/rubygems/rubygems/commit/d7b9c4532e

https://github.com/rubygems/rubygems/commit/f96fedf1f1

This will help centralize wheel platform selection logic eventually

Signed-off-by: Samuel Giddins <segiddins@segiddins.me>