term: fix eof hangup when pasting multiple of the libuv read buffer

[pkova]

There exists a longstanding bug that shows up when you paste text into the dojo with a length of any multiple of 123 characters. This is most easily reproduced by running (crip (reap 123 'a')) in the dojo and copy pasting the output back into the terminal.

The root cause turns out to be a misconfigured terminal. We specify a VMIN of 0 for our termios struct, which results in the following behavior.

MIN == 0, TIME == 0 (polling read)
If data is available, read(2) returns immediately, with the
lesser of the number of bytes available, or the number of
bytes requested.  If no data is available, read(2) returns 0.

Consider what happens when libuv tries to read exactly 123 characters with a buffer that's also 123 character large. The first read call will return all the characters but does not indicate that there aren't more characters to come. A second read call will thus be made returning 0.

Libuv of course has no idea that our terminal is this wonky so it reasonably assumes that the zero returned by read is EOF and dutifully stops the read handle, which explains why hang if we no-op in response to EOF without this fix:

https://github.com/libuv/libuv/blob/8fb9cb919489a48880680a56efecff6a7dfb4504/src/unix/stream.c#L1110-L1111
https://github.com/libuv/libuv/blob/8fb9cb919489a48880680a56efecff6a7dfb4504/src/unix/stream.c#L932-L939