Merge: Filereader fix

Merge: Filereader fix

Since 39fcf4a75aaec646f0b60d404dfcc5cb63dcb473 and because people prefer the Python/Ruby semantic to the C semantic, eof is blocking.

This PR rewrite `BufferedReader.read` to follow the Python/Ruby semantic: if there is 1 character in the system buffer, and that the programmer asks for 2, the program will wait to have 1 more character, that can block the whole program if we are waiting the missing character from some keyboard, pipe or tcp connection.

Here a comparaison of the various specifications:

The protocol is the following: I `read(4)` bytes from stdin and print them. On stdin, I write `ab\n` (3 bytes) then `cd\n` (3 other bytes) and see when the the read does Its job.
In the following, I only give the outputs since the input will be the same and adding it will require to distinguish them with the output.

~~~sh
$ ./nit_old -e 'print sys.stdin.read(4)'
a
~~~

WTF? Why only char `a` was printed? OK the implementation before the PR was more buggy than expected.

~~~sh
$ ./nit_new -e 'print sys.stdin.read(4)'
ab
c
~~~

As I expected, nothing is printed after the first `ab\n` because exactly 4 bytes are waited for, then printed. Thus we get `ab\nc`. The extra `d\n` are lost in the buffer of Nit.

~~~sh
$ ruby -e 'puts $stdin.read(4)'
ab
c
$ d
bash: d : commande introuvable
~~~

Same behavior with Ruby, so nothing is printed after the first `ab\n`.
Nice surprise however, the extra `d\n` are not lost but kept in system buffer, so still available (and read) when the shell take back the control. I am not really sure which behavior I prefer. The Ruby one might be saner from an OS point of view; but since I was surprised, one can assume that the POLA level is not that high.

~~~sh
$ python <(echo 'import sys;print(sys.stdin.read(4))')
ab
c
~~~

So exactly the same behavior than Nit with this PR.

Close #1264

Pull-Request: #1297
Reviewed-by: Jean Privat <jean@pryen.org>
Reviewed-by: Alexandre Terrasa <alexandre@moz-code.org>