FreeBSD /bin/sh test workaround, simple "call and response" test using bc(1)

[jquast]

• Workaround freebsd AT&T shell in test.
  • There is something I am not able to understand about /bin/sh on freebsd: This is actually some kind of "second output of input echo" that occurs only with the AT&T-compatible /bin/sh on FreeBSD, and intermittently (a modified version of the test runs forever on OSX and Linux). Full analysis in https://github.com/pexpect/ptyprocess/issues/12#issuecomment-96443761
  • The workaround is to gather all output to a single string, instead of individual line-by-line reads.
• Made only a slightly better "call and response/repl" test, but I ran into a lot of blockers.
  • It seems the non-gnu bc(1) (anything but Linux) somehow echos input to output, even when echo=False. I thoroughly tested the getecho/setecho/waitnoecho family of functions (and discovered PR #19 along the way). If I run "stty -echo" on bash, then bc, my input is most certainly not written to output.
  • My current theory is that there is a difference between executing bc(1) directly and setting terminal attributes rather than executing a shell, setting terminal attributes, then executing bc(1) from there. I just added a "note:" about not including an assertion for now.
• remove unused _is_irix
• skip waitnoecho tests on Solaris
• I saw /bin/false return something other than 1. Once.. just check non-zero status instead. https://teamcity-master.pexpect.org/viewLog.html?tab=buildLog&logTab=tree&filter=debug&expand=all&buildId=6228#_focus=2040

[jquast]

With these changes (to tests, only), I am confident in a ptyprocess v0.5, anyway. It will ensure "green" builds downstream for all OS's

(except for the remaining asyncio/EOF issue in pexpect, I hope to return to this specific issue after a short break)

[takluyver]

All looking good to me. Thanks!