Avoid repeated TTY readline output with TERM=dumb

[JoelTowell]

Problem

Reline's dumb IO gate can be attached to a TTY, but it cannot repaint one.

When TERM=dumb is set, Reline selects Reline::Dumb. inner_readline still drives the display machinery: it renders the line editor, rerenders after input changes, renders the accepted line, and then moves the cursor back to column 0.

That is fine for an IO gate that can move the cursor over the previous frame. It is an issue for Reline::Dumb, where the cursor movement methods intentionally do nothing. Reline::Dumb#buffered_output also just yields, so those render writes go straight to output.

With a TTY, submitted input is already echoed by the terminal. Reline then appends intermediate render output after that. Typing hello can produce output like:

0> hello
hhehelhellhello0> hello
"hello"

This is related to #660.

Reproduction

The first commit on this branch adds failing coverage for this. It runs Reline.readline twice under a PTY with TERM=dumb, so both input and output are TTYs.

It can be checked out independently to see the current behaviour.

Solution

Buffer writes inside Reline::Dumb#buffered_output when input and output are both TTYs.

The first buffered render is still written, so the prompt is visible. Complete lines are also still written, so accepted input remains visible in captured TTY output. Other render frames are dropped, because Reline::Dumb has no cursor operation that could apply them in place.

When input or output is not a TTY, buffered_output keeps yielding directly and preserves the existing write path.