When running a fresh `bundle install` with gems that contains
executables, Bundler will generate binstubs but soon after will remove
them. This is a regression introduced in https://github.com/ruby/rubygems/commit/573ffad3ea4a.

This results in doing `bundle install && bundle exec foo` to raise an
error saying `foo` couldn't be found.

This issue only appears if `BUNDLE_CLEAN` is set.

At the end of the installation process, when Bundler has installed
gems and generated binstubs, it runs the cleanup.

1. It [detects](https://github.com/ruby/rubygems/blob/4f8aa3b40cded3465bb2cd761e9ce7f8673b7fcb/bundler/lib/bundler/runtime.rb#L182) the executable for the current specs
2. Any existing executables not detected is then removed https://github.com/ruby/rubygems/blob/4f8aa3b40cded3465bb2cd761e9ce7f8673b7fcb/bundler/lib/bundler/runtime.rb#L194.

The issue being that 1. now returns an empty array where as it should
return the executables of the gems from the current bundle.

The problem is in https://github.com/ruby/rubygems/commit/573ffad3ea4a where we
removed the `executables` method from the `EndpointSpecification`.
When Bundler reads the lockfile, it creates a `EndpointSpecification`
object for each spec. At this point, the EndpointSpecification doesn't
know about the `executables` of a gem. Once Bundler fetches the
`gemspec` from the remote, it swaps the the "spec" with the real one
and from here knows what executables the gem has.

Reintroduce the `executables` method and the `bindir` in the
EndpointSpecification class. From what I'm seeing, the removal
of those wasn't needed to resolve the issue where Bundler remembers
CLI flags. This is probably an oversight.

https://github.com/ruby/rubygems/commit/b47f6b0247

https://github.com/rubygems/rubygems/commit/573ffad3ea

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

Since not every dependency gets referenced.

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

### Before

Total allocated: 295.01 MB (3624335 objects)
Total retained:  119.31 MB (1364474 objects)

### After
Total allocated: 288.21 MB (3498515 objects)
Total retained:  119.10 MB (1357976 objects)

https://github.com/rubygems/rubygems/commit/61eee39d81

Co-authored-by: Samuel Giddins <segiddins@segiddins.me>

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

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

It's defined in the superclass already.

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

Namely, when a gem has not previously been installed, and Bundler is
using the compact index API, fund metadata was not getting printed
because the proper delegation was not implemented in the specification
class used by the compact index.

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

Looks for the CHECKSUMS section in the lockfile, activating the feature
only if the section exists. Without a CHECKSUMS section, Bundler will
continue as normal, validating checksums when gems are installed while
checksums from the compact index are present.

https://github.com/rubygems/rubygems/commit/2353cc93a4

Not strictly necessary, but there is no reason not to be helpful and set the path

https://github.com/rubygems/rubygems/commit/894c0303dd