Checking the return value of `fgets` isn't good enough to determinewhether the input stream has reached EOF or not.  `fgets` could have runin to an error and returned NULL.  Additionally, we can't just check thebuffer contents for `\n` because `fgets` could have read the maximumbuffer size (which may not have ended with a `\n`).I want to use this callback to implement a fix for:https://bugs.ruby-lang.org/issues/21188

The purpose of this commit is to fix Bug #21188.  We need to detect whenstdin has run in to an EOF case.  Unfortunately we can't _call_ the eoffunction on IO because it will block.Here is a short script to demonstrate the issue:```rubyx = STDIN.getsputs xputs x.eof?```If you run the script, then type some characters (but _NOT_ a newline),then hit Ctrl-D twice, it will print the input string.  Unfortunately,calling `eof?` will try to read from STDIN again causing us to need a3rd Ctrl-D to exit the program.Before introducing the EOF callback to Prism, the input loop lookedkind of like this:```rubyloop do  str = STDIN.gets  process(str)  if str.nil?    p :DONE  endend```Which required 3 Ctrl-D to exit.  If we naively changed it to somethinglike this:```rubyloop do  str = STDIN.gets  process(str)  if str.eof?    p :DONE  endend```It would still require 3 Ctrl-D because `eof?` would block.  In thispatch, we're wrapping the IO object, checking the buffer for a newlineand length, and then using that to simulate a non-blocking eof? method.[Bug #21188]