Problem:
Only the stdio channel can "own" a server (self-exit on close). After
:restart the TUI reconnects over a socket, so the restarted server does
not have "self-exit" behavior when the channel closes (e.g. by UI
disconnect, host-terminal close, etc.), which leaves a dangling server.

Solution:
- Introduce `nvim_chan_set`. (`nvim_set_client_info` doesn't fit:
  exposing it to Lua would require a `channel` param, which is not
  backwards-compatible, plus it's awkward because it doesn't merge info.)
- Broadcast per-channel properties in the "restart" UI event as an
  opaque dict (a potentially useful pattern for other UI-events in the
  future).
  - UIs are expected to restore the channel properties on restart.
- `nvim_get_chan_info()` reports "detach".
- Remove `nvim__chan_set_detach()`.

Problem:
The magic globals `it`, `describe`, etc., are more trouble than they are
worth.

- Hooking into `after_each` requires `getfenv()` hacks.
- They confuse luals/emmylua, because the top-level `.luarc.json` isn't
  merged with `test/.luarc.json` (apparently a luals limitation?)
- They totally defeat discoverability because the user just has to
  "know" about the various magic symbols.

So they harm DX, which means they serve no purpose at all.

Solution:
- Expose the test API from `testutil`, so tests can call `t.it()`,
  `t.describe()`, etc., in the conventional way.
- Drop `getfenv()` hacks.
- Drop the `setfenv()` injection in `load_chunk`.
- Drop `test/_meta.lua`.

Problem:
`gx` relies on `exepath` to get the fullpath of `cmd.exe`,
and that path must use `\`; otherwise, luv's spawn will fail.

Solution:
Revert `slash_adjust` in `exepath`, so that it still respects 'shellslash'

Check that a pending event is actually cancelled, in place of the
nvim_subscribe that was removed in #28487.

Use a fast API, as a deferred API request may be aborted by EOF.

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.

Also close Nvim instance before removing log file, otherwise the Nvim
instance will still write to the log file.

Also adjust log level in libuv_process_spawn(). Ref #27660