inputManager : PostRestoreObject
Note that if this value is nil, it means only that we've never seen an InEvtNoTimeout return code from inputLineEvent - it does NOT mean that timeouts are supported locally.
We assume that the input functions are uniform in their treatment of timeouts; that is, we assume that if inputLineTimeout supports timeout, then so does inputEvent, and that if one doesn't support timeout, the other won't either.
If 'reset' is true, we'll clear any input state saved from the interrupted in-progress editing session; otherwise, we'll retain the saved editing state for restoration on the next input.
This MUST be called before calling tadsSay(). Games should generally never call tadsSay() directly (call the library function say() instead), so in most cases authors will not need to worry about calling this on output.
This MUST ALSO be called before performing any keyboard input. Callers using inputManager methods for keyboard operations won't have to worry about this, because the inputManager methods call this routine when necessary.
Note that this routine is not generally called directly; callers should usually call the convenience routines getKey() or getEvent(), as needed.
If allowRealTime is true, we'll execute any real-time events that are already due to run, and then we'll allow the input to be interrupted by real-time events, if interrupted input is supported on the local platform. Otherwise, we will not process any real-time events.
promptFunc is a callback function to invoke to display the prompt. This is provided as a callback so that we can re-display the prompt as necessary after real-time event interruptions. Note that if real-time interruption is not to be allowed, the caller can simply display the prompt before calling this routine rather than passing in a prompt callback, if desired.
If we're in HTML mode, this will switch into the 'tads-input' font while reading the line, so this routine should be used wherever possible rather than calling inputLine() or inputLineTimeout() directly.
In order to ensure that the display makes sense to the user, we flush any captured input in the transcript before pausing. We re-activate transcript capture after the pause if it was active before. Note that in some cases, this could affect the overall output for the command, since some commands wait until the very end of the command to go back and process the entire transcript for the command. Since we interrupt the transcript, flushing any output that occurred before the pause, a command that goes back over its entire output stream at the end of the turn won't be able to see or modify any of the output that occurred prior to the pause, since we will have flushed the output to that point.
If allowRealTime is nil, we won't process real-time events at all; we'll merely return nil for the timeout to indicate to the caller that any user input interaction about to be attempted should wait indefinitely.