Problem
-------

When running a subprocess that writes a lot of data to stdout, then
exits, it is possible to read all data from stdout, then, when calling
waitpid(2), to be told the subprocess has not yet exited.

pexpect would then call read_nonblocking and block for a full 30
seconds, because there remains no more data on stdout.

Solution
--------

Add new parameter, poll_exit to read_nonblocking so that select(2) is
called at shorter intervals than previously done, but still up until
timeout specified, doing a poll for waitpid(2) at regular intervals.
This ensures that no longer than (default, 0.15) seconds elapse, instead
of the default of 30.

Testing
-------

Includes travis changes for python3.4, also disabling use_site_packages
which doesn't appear supported any longer (most builds have been failing
for some time). Additionally, a 'death' flag for checking select(2)
after waitpid(2) was necessary only for python3.4 on travis, i could not
reproduce locally.

All existing unit tests, of course. However, as a race condition, it is
not possible to reliably reproduce, it may require anywhere from 1 to 5
minutes of looping to cause it to reproduce, so it was not put into base
tests.

A simple program was authored::

   TIMEOUT=1
   def test_2():
       while True:
           stime = time.time()
           child = pexpect.spawn('ls -lR /dev',
                                 timeout=TIMEOUT)
           child.expect(pexpect.EOF)
           elapsed = time.time() - stime
           print('got eof in {0:0.2f} in pid {1}'
                 .format(elapsed, child.pid))
           assert math.floor(elapsed) < TIMEOUT, elapsed

Without this change, this program will raise an exception after several
dozen runs, hitting the race condition.

With this change, I have been executing this program for several thousand
iterations without failed assertion.

PLEASE CONFER
-------------

@takluyver, with this change, I think we may also delete the
self.__irix_hack and its surrounding hack -- and even the first
self.isalive() check just before this change, for "some systems
such as Solaris" without any penalty in performance.

What do you think?

create a unit tests which otherwise failed for python3 only: mock the
return value of set_unique_prompt for a value of False, which causes
ExceptionPxssh to raise.

previously, displaying self.buffer within the exception causes
bytes() to be implicitly decoded to str (unicode type in py3). python2
didn't care. it is implicitly decoded as 'ascii' encoding, without
warning.

Then, use the %r to represent it as b'xyz' in python3. Also, display
what we expected to be more helpful for the user. What is actually
happening here is the 'set PS1=' command is used so that pexpect can
more regularly understand when the prompt is awaiting command input, and
it is set to something more predictable. You'd be suprised what kind of
hackery can happen to prompt values even if PS1 is explicitly set,
especially in today's oh-my-zhs and git-prompt.sh extensions.

Fedora build machines call signal.signal(signal.SIGHUP, signal.SIG_IGN)
as part of daemonizing, but this test needs the child process to use the
default signal handler.