- Make sure that proc->in is not NULL, because nvim crashed when
  starting a job with pty.
- Make sure that proc->out is not NULL, because nvim crashed when stopping
  a job opened with pty.

Handling of process exit is still broken.  It detects the moment when the
child process exits, then quickly stops polling for process output.  It
should continue polling for output until the agent has scraped all of the
process' output.  This problem is easy to notice by running a command like
"dir && exit", but even typing "exit<ENTER>" can manifest the problem --
the "t" might not appear.

winpty's Cygwin adapter handles shutdown by waiting for the agent to close
the CONOUT pipe, which it does after it has scraped the child's last
output.  AFAIK, neovim doesn't do anything interesting when winpty closes
the CONOUT pipe.

References ac055d677aa9
References #4370

Closes #4370

Explication:

    In the backtrace in #4370, we see that `buf_write()` was called with
    non-NULL `fname` and `sfname` arguments, but they've since _become_
    NULL.

    #7  0x00000000004de09d in buf_write (buf=0x1dee040, fname=0x0, fname@entry=0x1e985b0 "/home/sean/src/github.com/snczl/virta/pkg/meld/segment.go",
                                         sfname=0x0, sfname@entry=0x1ddfa60 "segment.go", start=1, end=72, eap=eap@entry=0x7ffc6b032e60, append=0,
                                         forceit=0, reset_changed=1, filtering=0)
    at /home/travis/build/neovim/bot-ci/build/neovim/src/nvim/fileio.c:2576

    This is most likely due to the code that restores those values from
    `buf`, which happens just before the fatal call to `os_fileinfo`

    ```c
        /*
         * The autocommands may have changed the name of the buffer, which may
         * be kept in fname, ffname and sfname.
         */
        if (buf_ffname)
          ffname = buf->b_ffname;
        if (buf_sfname)
          sfname = buf->b_sfname;
        if (buf_fname_f)
          fname = buf->b_ffname;
        if (buf_fname_s)
          fname = buf->b_sfname;
    ```

    It's worth noting that at this point `ffname` is still non-NULL, so
    it _could_ be used.  However, our current code is purely more strict
    than Vim in this area, which has caused us problems before (e.g.,
    `getdigits()`).  The commentary for `struct file_buffer` clearly
    indicate that all of `b_ffname`, `b_sfname`, and `b_fname` may be
    NULL:

    ```c
      /*
       * b_ffname has the full path of the file (NULL for no name).
       * b_sfname is the name as the user typed it (or NULL).
       * b_fname is the same as b_sfname, unless ":cd" has been done,
       *		then it is the same as b_ffname (NULL for no name).
       */
      char_u      *b_ffname;        /* full path file name */
      char_u      *b_sfname;        /* short file name */
      char_u      *b_fname;         /* current file name */
    ```

    Vim directly calls `stat(2)` which, although it is annotated to tell
    the compiler that the path argument is non-NULL, does handle a NULL
    pointer by returning a `-1` value and setting `errno` to `EFAULT`.
    This satisfies Vim's check, since it treats any `-1` return from
    `stat(2)` to mean the file doesn't exist (at least in this code
    path).

    Note that Vim's mch_stat() implementations on win32 and solaris
    clearly cannot accept NULL `name`. But the codepaths that call
    mch_stat will NULL `name` tend to be unix-only (eg: u_read_undo)!

This was broken in ye olde refactor from 2014:
e85fe0957d40080f43cbfcbe9eb8864475325b09

References #4370