Problem:
chan_close_on_err() writes to the log file before peforming its actual
work. This could be slightly misleading in terms of log timestamps, or
could delay important work on Windows where file-open/write can be slow.

Solution:
Log after closing the channel, instead of before.

Problem:
`receive_msgpack()` calls `channel_close()` just before calling
`chan_close_on_err()`, even though `chan_close_on_err()` always calls
`channel_close()`.

Solution:
Remove the redunant `channel_close()` in `receive_msgpack()`.

When a UI detaches it will execute any UILeave events. Autocommands
cannot run in a libuv handler because they will in turn poll the event
loop, which results in recursive loop execution. So we schedule the
callback to detach the UI on the main event queue.

We also have to schedule the exit when the RPC channel is closed to
ensure it does not run until after `remote_ui_disconnect` has run,
otherwise it will hang.

Problem:
on_proc_exit() has a special-case that assumes that the UI client will
never spawn more than 1 child process.

Solution:
If the Nvim server exits, the stream EOF will trigger `rpc_close()` in
the UI client, so we don't need the special case in `on_proc_exit`.
Pass `Channel.exit_status` from `rpc_close()` so that the correct exit
code is reflected.

Problem:
Cannot detach the current UI.

Solution:
- Introduce `:detach`.
- Introduce `Channel.detach`.

Co-authored-by: bfredl <bjorn.linse@gmail.com>

Problem:
RPC log messages show `log_notify` function name, which is not useful:

    DBG 2025-02-04T22:28:02.419 ui.37862   log_notify:57: RPC -> 3: [notify]    nvim_ui_set_focus
    DBG 2025-02-04T22:28:02.419 nvim.37863.0 log_notify:57: RPC <- 1: [notify]    nvim_ui_set_focus

Solution:
Call logmsg() directly.

    DBG 2025-02-04T22:42:00.104 ui.40680   RPC: -> 3: [notify]    nvim_ui_attach
    DBG 2025-02-04T22:42:00.104 ui.40680   RPC: -> 3: [notify]    nvim_set_client_info

Result of `make iwyu` (after some "fixups").

In the api_info() output:

    :new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val')
    ...

    {'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1}

The `ArrayOf(Integer, 2)` return type didn't break clients when we added
it, which is evidence that clients don't use the `return_type` field,
thus renaming Dictionary => Dict in api_info() is not (in practice)
a breaking change.

Problem:
- "process" is often used as a verb (`multiqueue_process_events`), which
  is ambiguous for cases where it's used as a topic.
- The documented naming convention for processes is "proc".
  - `:help dev-name-common`
- Shorter is better, when it doesn't harm readability or
  discoverability.

Solution:
Rename "process" => "proc" in all C symbols and module names.