test asserting that gosh.Sh commands do not see themselves as owning a tty.  nothing new here.

note that if you string up os.Stdin and os.Stdout to the command, those see themselves as owning a tty if the process itself owns a tty, which is often a reasonable thing to do.  However that can't really be done in a test.
link to kr's pty library.

will need this shortly.
fix typo in test method name
ReaderFromInterface and WriterFromInterface now return ReadCloser and WriteCloser if possible.  Those methods are now documented with what types can be refined.

WriterFromInterface can produce a WriteCloser from both chan and chan<- types, which is entirely reasonable.  ReaderFromInterface returns ReadClosers for chan types, but Reader for <-chan types, which is entirely disgusting.  I have no idea why golang decided that the read size of a channel shouldn't support a close operation.  The fact that a ReadCloser interface exist seems like a clear enough argument to me that close(<-chan) ought to exist as well, if for no other reason than parity.
RunningCommand.Start() now returns the same object for chaining convenience.
Remove comical todo that's long since done.
Add Pid() accessor to RunningCommand.
Dramatically improve reliablity of exit code handling.

Signals that cause process termination are now reported in the same way as bash reports them; previously they were a nondescript -1.

Waiting for exit now actually works correctly under *all* circumstances; previously certain states ignored even by the golang stdlib os.exec.Cmd could cause waiting to incorrectly return for a still live process.  Worked around this by using the slightly deeper os.Process.Wait() and inspecting the waitstatus ourselves.  Many unit tests for this, because good lord is it a finicky business.