Don't require pressing Return when selecting a gem

[eval]

I opened this discussion a few weeks ago but it didn't get a response yet - so following up with a concrete implementation to make the proposal easier to evaluate. Happy to adjust the approach based on feedback.

What was the end-user or developer problem that led to this PR?

When using commands info, show, open with an ambiguous search-term (e.g. bundle show rspec), a menu with numbered candidates is shown. Selecting one always required confirming with Return, which adds friction to what is usually a single-digit choice.

What is your fix for the problem, implemented in this PR?

The menu now accepts a selection on a single keypress, so no extra Return is needed in the common case:

• ≤ 9 options → any digit selects immediately, no Return.
• ≥ 10 options → only digits that are a prefix of a larger number wait (e.g. 1 when 10/11 exist); everything else (2–9, 0) still fires instantly. Return resolves the prefix to what's typed so far (e.g.
  selecting 1 while 10 exists). Backspace edits the entry, digits that can't lead to any valid option are ignored.

Terminal control keys behave conventionally:

• Ctrl-C aborts with the standard SIGINT exit status (130), without printing a backtrace. (It can't simply re-raise Interrupt, because with_friendly_errors re-raises SignalException to the interpreter (see Avoid bundle exec rescue of SignalException rubygems/bundler#6092) - which would dump a backtrace; so it exits explicitly with 128 + SIGINT.)
• Ctrl-D / EOF cancels (no selection), exiting 0. This matches the previous line-based prompt, where EOF made nil.to_i return 0.

The single-keypress path is only used when both stdin and stdout are a TTY and io/console is available. Otherwise (piped input, non-interactive shells, CI) it falls back to the existing line-based prompt, so scripted usage and existing specs are unaffected.

The discussion raised whether this should be opt-in via configuration. I've kept it on by default, since the non-TTY fallback means scripts and CI are unaffected and the change to interactive use is minimal. I'm happy to gate it behind a config setting if maintainers prefer.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags