This is a very weird Windows-specific regression.
Currently, when we call read_stdout or read_stderr repeatedly, the function returns these three distinct results:

1. "<data>": We read something
2. "": There is no data available / stream is closed (EOF)
3. nil: An error occured or the process has exited and we hit EOF

This is a weird status quo, but well, killing the process when stream closes is not good, and I am not here to rethink the design.

On Windows, this is not the case due to how ReadFile and OVERLAPPED IO works.

On Linux:

read() == 2, errno == 0 // read 2
read() == -1, errno == EAGAIN // stream has no data
read() == 2, errno == 0 // read 2
read() == 0, errno == 0 // stream hits EOF

On Windows:

(1) ReadFile() == true, dwBytesTransferred == 2, GetLastError() == ERROR_SUCCESS // read 2
(2) ReadFile() == false, dwBytesTransferred == 0, GetLastError() == ERROR_IO_PENDING // stream has no data
(3) GetOverlappedResult() == true, dwBytesTransferred == 2, overlapped.Internal = ERROR_SUCCESS // read 2
(4) ReadFile() == false, dwBytesTransferred == 0, GetLastError() == ERROR_IO_PENDING // stream has no data
(5) GetOverlappedResult() == true, dwBytesTransferred == 0, GetLastError() == ERROR_EOF_HANDLE // stream hits EOF
(6) ReadFile() == false, dwBytesTransferred == 0, GetLastError() == ERROR_HANDLE_EOF // stream hits EOF

The code is somewhat equivalent, but on Windows OVERLAPPED IO operates on completion, so one can think of GetOverlappedResult() and ReadFile() can be merged into a single operation here. For that reason, the synchronous read branch is not shown.

The problem lies in (5) and (6). When (5) fails with ERROR_EOF_HANDLE, Lite XL ignores this error code and pretends that it does a 0-size read. That's fine. But when (6) comes around, Lite XL thought that some other error has occured and kills the program. This is not the case on Linux:

On Linux, we only kill the process if we hit an actual pipe error, we never kill the process because we hit EOF. When we hit EOF, we continue to return an empty string until the process dies.

On Windows:

The Windows code is really terse and hard to read, but the takeaway is the code will kill the process no matter what happened, as long as it didn't read a thing, like EOF. The function also don't return an empty string until the process actually dies, it also doesn't call poll_process() which causes an edge case of calling process:returncode() right after read_stdout() fails to not work.

This PR emulates the POSIX behavior of calling poll_process when we hit EOF. This will fix the aforementioned edge case, and returns an empty string until the process actually exits.