On input(..) use Sk.inputfun only if sys.stdin has not been overwritten.

[skiadas]

Problem: How to handle input and raw_input when sys.stdin is overwritten, e.g. via sys.stdin = StringIO.StringIO(...).

• Under normal conditions, Sk.inputfun should eventually be called, and may function like a browser alert including the prompt in the alert, and asking the user to supply the input.
• However if sys.stdin is overwritten, then this function should not be called, and instead the input should be read from the overwritten sys.stdin.

Currently what happens is the following:

• input/raw_input (Sk.builtin.raw_input) checks to see whether Sk.inputfunTakesPrompt is true or not. If it is false then writes the prompt via sys["$d"]["stdout"]["write"] and reads the input via sys["$d"]["stdin"]["readline"]. This is OK behavior.
• However if Sk.inputfunTakesPrompt is true, then raw_input directly calls on Sk.builtin.file.$readline because that method takes an extra prompt argument.
• This Sk.builtin.file.$readline is hard-coded to use Sk.inputfun when the fileno is 0 (i.e. when the sys.stdin has not been overwritten).
• If sys.stdin has been overwritten with e.g. StringIO(...), then while sys["$d"]["stdin"]["readline"] would have activated the correct StringIO readline, the Sk.builtin.file.$readline that runs instead basically executes the file.js readline but with a StringIO object. The result is expected errors when the various file.js properties are being accessed, e.g. self.lineList.length.
• We cannot replace the call to Sk.builtin.file.$readline with a call to sys["$d"]["stdin"]["readline"] as the latter knows nothing about prompts and so can't handle the behavior of input by itself.
• This PR addresses this by checking at raw_input whether sys.stdin has been overwritten (by having the wrong fileno) and if it has been overwritten then it uses sys["$d"]["stdin"]["readline"] instead, with any possible prompt written to sys.stdout.