New tty state handling

[jcburley]

Leave terminal state unchanged until actually prompting and waiting for input.

Support ^Z to suspend (with restored input) and SIGCONT to continue (going back to raw mode to continue reading input).

Support ^\ (SIGQUIT) delivery.

Support Windows.

This makes liner better for programs like Joker that aren't trying to be proper shells, but rather support interactive input such as for REPLs within the context of a shell such as bash or zsh.

For example, if the host program reads input on its own (as might Joker via the REPL), or is killed via e.g. SIGQUIT while running host code (versus being at a liner prompt), the terminal state will not be in raw mode at that time, so the user need not reset the terminal back to raw state to see input echoed back, among other things.

I tested this out using https://github.com/jcburley/echo with the -line-reader peterh/liner command-line option. However, I've tested it only on Mac OS X and Ubunu; back when I first made these changes for @candid82's fork of liner, they worked there and on Windows 7, but I don't have access to my Windows 7 or Windows 10 machines while on vacation.

[peterh]

Functional changes:

• I'm not happy about the change to the terminal mode. I prefer the terminal mode to stay non-echo until Close() is called. In regards to "reset", remember to "defer l.Close()" to make sure it gets cleaned up if/when a crash happens (and/or call l.Close() before calling os.Exit() in your signal handlers?). Even if I was happy with the idea, this sort of change seems like it would have to wait for a major version change.
• I don't like fmt.Println("^Z [unsupported on Windows]"). I'm not convinced that job control while the prompt is showing is an improvement, but I could perhaps be persuaded if Windows was cleaned up.

Administrative comments:

• There are two unrelated things in this pull request (signal handling / job control, and terminal mode policy changes). It would be much easier to review if these changes were in separate pull requests. (In this particular instance, I'm not going to pull the terminal mode changes, so that sinks the job control changes by proxy).
• There are WIP commits in here, with a broken bisect. This sort of thing needs to be cleaned up before I can consider pulling (git rebase -i is your friend).

[jcburley]

No worries, I figured it might be too much in one PR, but wasn't comfortable trying to break it out and test it individually while away on vacation with limited access. At least it continued the conversation in a useful direction.

I'll look at this again sometime after I return (next week) and see if I can figure out how best to parcel out PRs that might be acceptable. Any guidance would be appreciated.

(As an aside, having grown up using a KSR-33 teletype on TOPS-10, I too found immediate echoing of input while a program was running to be distracting when I moved to other OSes; so I understand that viewpoint. It's not how Unix does things generally, but Unix isn't the only OS or CLI style out there....)