Need to wait for pty response well

[YO4]

TestVTerm somtime fails like:

Failure: test_fullwidth(Yamatanooroti::TestMultiplatform::TestVTerm):
  </=> :あ\nprompt>/> was expected to be =~
  <"prompt> :あ\n">.
/home/runner/work/yamatanooroti/yamatanooroti/lib/yamatanooroti/vterm.rb:161:in `block in assert_screen'
/home/runner/work/yamatanooroti/yamatanooroti/lib/yamatanooroti/vterm.rb:141:in `retryable_screen_assertion_with_proc'
/home/runner/work/yamatanooroti/yamatanooroti/lib/yamatanooroti/vterm.rb:159:in `assert_screen'
/home/runner/work/yamatanooroti/yamatanooroti/test/yamatanooroti/test_multiplatform.rb:59:in `test_fullwidth'
     56:   def test_fullwidth
     57:     write(":あ\n")
     58:     close
  => 59:     assert_screen(/=> :あ\nprompt>/)
     60:     assert_equal(['prompt> :あ', '=> :あ', 'prompt>', '', ''], result)
     61:   end
     62: 

https://github.com/ruby/yamatanooroti/actions/runs/11032616108/job/30641945856?pr=12

This failure appears to be due to close being too early.

Some investigations

write triggers the following processes
(1) pty write
(2) pty read
(3) vterm write
(4) vterm read
(5) pty write if (4), and go to (2)

(3)..(5) are synchronous process.
only (2) is asynchronous and undetermined process.

The combinations of processes that cause problems are as follows

• write then close
  close in spite of remaining undelivered data will lost following data.
• write then write
  Potentially performing (1) while there is undelivered data will result in mis-ordering of data.

Proposed Solution

If it can be assumed that there is always data available to be read from the pty after a write to the pty, it is possible to wait longer for data and keep the processing order correct.

[tompng]

write then close

After closing, yamatanooroti can't wait for a long time not to make test slow.
We can now perform assert_screen several times before close, and I think the test is not good. #24 will fix the test flakyness.
If someone wants to close input before assertion, Yamatanooroti needs to implement #15.

mis-ordering

Considering running TUI program through SSH(or through some other network with delay), mis-ordering always happens. Reline implements mechanism to read mis-ordered cursor position response.
I think the chance of mis-ordering is low enough. To decrease mis-ordering, I think #16 is what we need.

[YO4]

Closed PR #23 mainly addresses closing issue. #24 resolves this.
Keeping ordering is side effect. It can reduce unpredictability I thought.
But mis-ordering is something that can happen, keeping ordering is not necessary.

Testing with mis-ordering may be necessary, but that should be an another issue.