Support `ruby-build ruby-X.Y.Z DIR`

[eregon]

• By searching a X.Y.Z definition if no ruby-X.Y.Z definition is not found.

So this enables for example:

$ ruby-build ruby-3.3.5 PREFIX

And with https://github.com/rbenv/ruby-build/pull/2447 it enables:

$ ruby-build -d ruby-3.3.4 ~/.rubies
...
==> Installed ruby-3.3.4 to /home/eregon/.rubies/ruby-3.3.4

It would remove the need for https://github.com/ruby/ruby-builder/blob/135bc7c215df24a672d0735189aafc510923d380/.github/workflows/build.yml#L67-L74 and likely other places working around the "asymmetry" that CRuby definitions don't have a prefix.

[eregon]

But first of all: without #2447 I don't think this feature makes sense on its own, so I would even suggest lumping it together in a single PR rather that treating them as distinct features. WDYT?

It's how I had it locally but I figured it's easier to review independently, and this change has value on its own (first example and last paragraph of the description). I can move it to #2447, or we can just merge both PRs, as you prefer, let me know.

I'm asking because it seems that if you add the -d option to this invocation, you will end up with different installation prefixes based on your argument input.

Indeed it will install to either $PREFIX/3.3.4 or $PREFIX/ruby-3.3.4. What I would like to achieve is to install to $PREFIX/ruby-3.3.4 with the -d option. I can see both sides:

• It installs to $PREFIX/$(first argument passed to ruby-build) (current behavior on the PR)
• ruby-X.Y.Z is resolved to X.Y.Z earlier, but then this could be a compatibility issue if someone has a custom definition matching ^ruby-[0-9] as then it wouldn't be picked anymore. So that's why I didn't go that way.

[eregon]

Amazing, thank you!