This will help centralize wheel platform selection logic eventually

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

https://github.com/rubygems/rubygems/commit/96496e3f53

Co-authored-by: Johnny Shields <johnny.shields@gmail.com>

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

I think they add unnecessary indirection and inconsistency to the specs.

https://github.com/rubygems/rubygems/commit/609924d985

It's always going to be either the first or the second platform in the
list so no need to keep an explicit list of all platforms.

https://github.com/rubygems/rubygems/commit/5d3cdb3855

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

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

Since we started locking the specific platform in the lockfile, that has
created an annoying situation for users that don't develop on Linux.
They will create a lockfile on their machines, locking their local
platform, for example, darwin. But then that lockfile won't work
automatically when deploying to Heroku for example, because the lockfile
is frozen and the Linux platform is not included.

There's the chance though that resolving against two platforms (Linux +
the local platform) won't succeed while resolving for just the current
platform will. So, instead, we check other platform specific variants
available for the resolution we initially found, and lock those
platforms and specs too if they satisfy the resolution.

This is only done when generating new lockfiles from scratch, existing
lockfiles should keep working as before, and it's only done for "ruby
platforms", i.e., not Java or Windows which have their own complexities,
and so are excluded.

With this change, we expect that MacOS users can bundle locally and
deploy to Heroku without needing to do anything special.

https://github.com/rubygems/rubygems/commit/5f24f06bc5

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