Problem:

Nvim tries to use OSC 52 even when no TUIs are attached.

Solution:

On each UIEnter/UILeave event, check that there is a TUI client connected to Nvim's stdout.

Always allow the following four events to be nested, as they may contain
important information, and are triggered on the event loop, which may be
processed by a blocking call inside another autocommand.

- ChanInfo
- ChanOpen
- TermRequest
- TermResponse

There are some other events that are triggered on the event loop, but
they are mostly triggered by user actions in a UI client, and therefore
not very likely to happen during another autocommand, so leave them
unchanged for now.

Problem:

When a function like vim.wait() is used, we continuously drain the main
event queue until it is empty, never stopping for user input. This means
the libuv timer never runs and the terminal never gets refreshed, so
emit_termrequest continously reschedules itself onto the same event
queue, causing an infinite loop.

Solution:

Use a separate "pending" event queue, where events that require a
terminal refresh are temporarily placed. Drain this queue after a
terminal refresh and events are copied back onto the main queue. This
prevents infinite loops since the main event queue will always be able
to properly drain.

Problem: terminal mode cursor refresh logic has too many edge cases where it
fails when events change curbuf.

Solution: change the logic. Introduce cursor_visible to TerminalState to more
reliably track if terminal mode has changed busy. Move visibility handling to
refresh_cursor and move its call in refresh_terminal to terminal_check to avoid
temporarily changed curbufs from influencing cursor state.

This has the effect of "debouncing" shape/visibility updates to once per
terminal state tick (with the final attributes taking effect, as expected). I
think this is OK, but as a result it may also be warranted to update when
redrawing during the same state tick (e.g: from events executing :redraw); this
can be added later, if wanted.

Also move previous tests to a more appropriate place.

When a plugin registers a TermRequest handler there is currently no way
for the handler to know where the terminal's cursor position was when
the sequence was received. This is often useful information, e.g. for
OSC 133 sequences which are used to annotate shell prompts.

Modify the event data for the TermRequest autocommand to be a table
instead of just a string. The "sequence" field of the table contains the
sequence string and the "cursor" field contains the cursor
position when the sequence was received.

To maintain consistency between TermRequest and TermResponse (and to
future proof the latter), TermResponse's event data is also updated to
be a table with a "sequence" field.

BREAKING CHANGE: event data for TermRequest and TermResponse is now a
table

Problem: after #32458, it may still be possible for `busy_start` UI events to be
emitted without matching `busy_stop`s in the terminal.

Solution: do `terminal_enter`'s cursor visibility check immediately after
setting/restoring State so it occurs before events. This ensures that if pending
escape sequences are processed while in `terminal_enter`, the cursor's initial
visibility is set before `is_focused` is checked by `term_settermprop`.

As a result, we can move the call to `showmode` back to where it was originally.

Problem: `showmode` in `terminal_enter` may cause `vpeekc` to process events,
which may handle pending escape sequences. If `CSI ? 25 l` is handled to hide
the cursor, it may remain hidden even after leaving terminal mode if both
`terminal_enter` and (indirectly) `showmode` call `ui_busy_start`, as there is
only one matching call to `ui_busy_stop` after leaving terminal mode.

Solution: let `terminal_enter` handle setting the initial visibility of the
cursor before calling `showmode`.

Closes #32456.

This simple solution assumes it isn't possible for e.g. `os_breakcheck` to be
called indirectly by something else before `terminal_enter` initially handles
cursor visibility and after it restores it, which I think is true.

Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>

Problem:
On Windows, spawning the `nvim --embed` server with `detach=true` breaks
various `tt.setup_child_nvim` tests.

Solution:
Make this behavior opt-in with an env var, temporarily.