The generic Ruby platform was getting unconditionally added in
truffleruby, preventing resolution in situations where there's no
generic ruby version (sorbet-static). Instead, the generic platform
should be considered per dependency, not globally.

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

This will help centralize wheel platform selection logic eventually

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

My application spends more than 30% of time during `bundle update`
comparing versions due to versions being sorted inside
next_package_to_try. This has been addressed in pub_grub by defining a
strategy interface (a `#next_package_and_version` method) which allows
consumers to have finer control over the heuristic to select the next
package to try.

This commit implements the new strategy interface to remove extraneous
version sorting (previously in next_package_to_try) since only the final
count of versions is used.

Combined with a previous change to pub_grub (already applied to
Bundler), this commit results in `bundle update` taking only half the
time it did on 2.6.5.

https://github.com/rubygems/rubygems/commit/62f69e27f0

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

In a large application I profiled allocations while running `bundle
update` and found that this method was ~60% of allocations while
resolving (and Candidate#<=> is almost half of the total runtime).

This commit removes the array allocation in Candidate#<=> (and similar
methods since the implementations are so simple). The array is always
the same two elements so they can just be compared directly.

https://github.com/rubygems/rubygems/commit/6a7c411ba7

Resolver had internal logic to prioritize locked versions when sorting
versions, however part of it was not being actually hit because of how
unlocking worked in the resolver: a package was allow to be unlocked
when that was explicit requested or when the list of unlocks was empty.
That did not make a lot of sense and other cases were working because
the explicit list of unlocks was getting "artificially filled".

Now we consider a package unlocked when explicitly requested (`bundle
update <package>`), or when everything is being unlocked (`bundle
install` with no lockfile or `bundle update`).

This makes things simpler and gets the edge case added as a test case
working as expected.

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

https://github.com/rubygems/rubygems/commit/7f921aa46e

They use less memory that way.

When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:

### Before

Total allocated: 265.06 MB (3186053 objects)
Total retained:  116.98 MB (1302280 objects)

### After

Total allocated: 262.99 MB (3177437 objects)
Total retained:  115.91 MB (1297821 objects)

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

Sometimes we'll resolve using bare `Gem::Dependency` instances rather
than `Bundler::Dependency` instances, which is fine, simpler, and saves
some memory.

When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:

### Before

Total allocated: 277.48 MB (3384318 objects)
Total retained:  117.53 MB (1338657 objects)

### After

Total allocated: 265.06 MB (3186053 objects)
Total retained:  116.98 MB (1302280 objects)

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

Even if they don't match the current Ruby version, they could still work
in other rubies. So it's better to keep them.

https://github.com/rubygems/rubygems/commit/9a3e583b0c