Problem:
When a TUI client is suspended it still receives UI events from the
server, and has to process these accumulated events when it is resumed.
With mulitple TUI clients this is a bigger problem, considering the
following steps:
1. A TUI client is attached.
2. CTRL-Z is pressed and the first client is suspended.
3. Another TUI client is attached.
4. CTRL-Z is pressed and a "suspend" event is sent to both clients. The
   second client is suspended, while the first client isn't able to
   process the event because it has already been suspended.
5. The first client is resumed. It processes the accumulated "suspend"
   event and suspends immediately.

Solution:
Make a TUI client detach on suspend and re-attach on resume.

This prevents the TUI from doing unexpected things when receiving a
deadly signal or running out of memory.

This allows us to get rid of the separate "nvim-test" target

This fixes a regression from #21605 that stdin is no longer set as
"blocking" after Nvim TUI exits, and the problems described in #2598
happen again.

I'm not sure if this should be done in TUI code or common exiting code.
I added this call in tui_stop() as it is also present in tui_suspend().

Saves two bits for reuse for new features

fix(ui): re-organize tty fd handling and fix issues

- Use the correct fd to replace stdin on windows (CONIN)
- Don't start the TUI if there are no tty fd (not a regression,
  but makes sense regardless)
- De-mythologize "global input fd". it is just STDIN.

Also add the EXITFREE definition to main_lib rather than the nvim target, as the header generation needs the EXITFREE flag to work properly.