Before calling "attach" a screen object is just a dummy container for
(row, col) values whose purpose is to be sent as part of the "attach"
function call anyway.

Just create the screen in an attached state directly. Keep the complete
(row, col, options) config together. It is still completely valid to
later detach and re-attach as needed, including to another session.

This mostly means replacing `nvim_buf_call` and `nvim_win_call` with
`vim._with`.

Problem:
`vim.rpcnotify(0)` and `rpcnotify(0)` are documented as follows:

    If {channel} is 0, the event is broadcast to all channels.

But that's not actually true. Channels must call `nvim_subscribe` to
receive "broadcast" events, so it's actually "multicast".

- Assuming there is a use-case for "broadcast", the current model adds
  an extra step for broadcasting: all channels need to "subscribe".
- The presence of `nvim_subscribe` is a source of confusion for users,
  because its name implies something more generally useful than what it
  does.

Presumably the use-case of `nvim_subscribe` is to avoid "noise" on RPC
channels not expected a broadcast notification, and potentially an error
if the channel client reports an unknown event.

Solution:
- Deprecate `nvim_subscribe`/`nvim_unsubscribe`.
  - If applications want to multicast, they can keep their own multicast
    list. Or they can use `nvim_list_chans()` and `nvim_get_chan_info()`
    to enumerate and filter the clients they want to target.
- Always send "broadcast" events to ALL channels. Don't require channels
  to "subscribe" to receive broadcasts. This matches the documented
  behavior of `rpcnotify()`.

Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.

Closes https://github.com/neovim/neovim/issues/27004.

Work on https://github.com/neovim/neovim/issues/27004.

Problem:  Things that temporarily change/restore curwin/buf (e.g:
          win_execute, some autocmds) may break assumptions that
          curwin/buf is the cmdwin when "cmdwin_type != 0", causing
          issues.

Solution: Expose the cmdwin's real win/buf and check that instead. Also
          try to ensure these variables are NULL if "cmdwin_type == 0",
          allowing them to be used directly in most cases without
          checking cmdwin_type. (Sean Dewar)

Reset and save `cmdwin_old_curwin` in a similar fashion.
Apply suitable changes for API functions and add Lua tests.

https://github.com/vim/vim/commit/988f74311c26ea9917e84fbae608de226dba7e5f

- remove helpers.cur*meths
- remove helpers.nvim