It's confusing to mix vendored dependencies with neovim source code. A
clean separation is simpler to keep track of and simpler to document.

Some V512 warnings have changed to V1086, and PVS apparently does not
know `uv_run()` can change `*timeout_expired`.

Problem:    Macros for MS-Windows are inconsistent, using "32", "3264 and
            others.
Solution:   Use MSWIN for all MS-Windows builds.  Use FEAT_GUI_MSWIN for the
            GUI build. (Hirohito Higashi, closes vim/vim#3932)
https://github.com/vim/vim/commit/4f97475d326c2773a78561fb874e4f23c25cbcd9

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

In the rare case that exit_event is called from process_close_handles,
it stalls waiting for the process to exit (the routine is currently
underway to do just that). This causes `job_spec.lua` to sometimes
stall.

REJECTED IDEAS:
==============================================================
1. Currently `exit_event` is placed on `main_loop.fast_events`. Would the problem
   be solved by using `main_loop.events` instead?
    - A: Maybe, but it will cause other problems, such as queuing exit_event()
      during "Press Enter..." prompt which may result in the event not being
      processed, leading to another stall.
2. Can we avoid the timer?
    - A: Using a timer is just the easiest way to queue a delayed event without
      causing an infinite loop in the queue currently being processed.
3. Can we avoid the new `exit_need_delay` global...
    1. by using `process_is_tearing_down` instead?
        - A: Can't use `process_is_tearing_down` because its semantics are different.
    2. by checking a similar condition as `process_teardown`? https://github.com/neovim/neovim/blob/f50135a32e11c535e1dc3a8e9460c5b4e640ee86/src/nvim/event/process.c#L141-L142
       ```
       if (!process_is_tearing_down || (kl_empty(main_loop.children) && multiqueue_empty(main_loop.events))) {
         uv_timer_start(&main_loop.exit_delay_timer, exit_delay_cb, 0, 0);
         return;
       }
       ```
        - A: Tried but it did not work (other stalls occurred). Maybe
          exit_event() is called from a source other than
          process_close_handles() and is delayed, the delayed exit_event() will
          be executed before main_loop.events is processed, resulting in an
          infinite loop.

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

Problem:
1. Log messages (especially in CI) are hard to correlate with tests.
2. Since b353a5c05f02 #11886, dumplog() prints the logs next to test
   failures. This is noisy and gets in the way of the test results.

Solution:
1. Associate an incrementing id with each test and include it in log
   messages.
    - FUTURE: add v:name so Nvim instances can be formally "named"?
2. Mention "child" in log messages if the current Nvim is a child (based
   on the presence of $NVIM).

BEFORE:

    DBG … 12345      UI: event
    DBG … 12345      log_server_msg:722: RPC ->ch 1: …
    DBG … 12345      UI: flush
    DBG … 12345      inbuf_poll:444: blocking... events_enabled=1 events_pending=0
    DBG … 23454      UI: stop
    INF … 23454      os_exit:594: Nvim exit: 0

AFTER:

    DBG … T57        UI: event
    DBG … T57        log_server_msg:722: RPC ->ch 1: …
    DBG … T57        UI: flush
    DBG … T57        inbuf_poll:444: blocking... events_enabled=1 events_pending=0
    DBG … T57/child  UI: stop
    INF … T57/child  os_exit:594: Nvim exit: 0

Suppress warning in loop.c, the expression can be true if EXITFREE isn't
defined.