Test and document PC_MAX_CANON.

Closes issue #55
Test and document PC_MAX_CANON.

Closes issue #55.

I suspect since stdin is not a tty for travis,
that it is "failing", but try Trying maximum
of either/or PC_MAX_INPUT as well before I
go forcing icanon.
Merge branch 'doc-and-test-max-canon' of github.com:pexpect/pexpect into doc-and-test-max-canon
Merge branch 'doc-and-test-max-canon' of github.com:pexpect/pexpect into doc-and-test-max-canon
Merge branch 'doc-and-test-max-canon' of github.com:pexpect/pexpect into doc-and-test-max-canon
Dealing with travis, force-set icanon
Finish canonical mode processing docs and tests

Linux is certainly the rotten egg in this respect, I could find
the code for sending '\a' for canonical mode processing in the
various kernel drivers within just a few minutes -- with the exception
of linux. After several hours of investigation of the kernel tty
driver, I still can't find where exactly '\a', '0x07', or 'BEL'
is sent.

We just trust that it is, verified on debian Linux. We also discover
that PC_MAX_CANON is not used, but rather, a hardcoded value inside
the kernel driver of 4096; the length of a ring buffer data structure,
also tested by the distance of head <-> tail of such ring buffer.
document this issue as a "common issues".

I'm not sure entirely how common this is,
as somebody who runs into the issue, this might
be the first place I'd look ..
remove unicode literals u'' from tests

Travis python 3.2 is timing out, we might have to
increase the timeout, i hope... I'm testing on debian
linux ..
increase timeout by 2 seconds for travis-ci

hail mary.
some more travis-ci accomidations

python3.2 and 3.4 on travis-ci are not flushing data to
child processes' stdin, presumably because CR is not yet
sent. tests are modified to always use sendline().

python3.2 on debian linux does not exhibit this same
behavior, so this is another hail mary.  if we can't get
travis-ci to agree, we might just scrap these tests all
together, it only confirms and examplifies the behavior
documented in send().
attempt one remaining error for py3.2 on travis-ci

we know that sendline() wouldn't work once we've reached the buffer,
but on travis-ci, this means stdin sent *still* has not been flushed
or received by the child process -- for python3.2 only. So we go
ahead and send backspace and sendline *prior* to testing echo output
and bel. I'm not entirely sure we will see BEL where we expect, only
travis-ci can say for sure. It is passing on debian linux py3.2,
though.
man 2 sleep is failing again on travis due to low timeout
display .buffer, we need the full thing

having a difficult time finding why travis is not finding the full send_bytes of '_'
on *only* python3.3 unlike local debian/linux vm? -- however noticed the "man sleep"
also failed there due to TIMEOUT, so it could just be terribly slow, requiring more
than 5 second timeout -- we'll see ...
Just skip tests on Travis-CI.

Last test python3.2 failed, all others passed.
This time, many python2.7 failed, all others passed.

There doesn't seem to be any consistant behaviour here, I give in.
SunOS has slightly different PC_MAX_CANON behavior

1. limit is actually PC_MAX_CANON + 1
2. BEL is not emitted *until* CR is sent
3. must use "stty erase ^H" for sendcontrol('h') to erase.
BEL is rang only once for both Solaris and Linux

... lets check BSD
Longer timeout for travis-CI for repl man 2 sleep
Merge branch 'doc-and-test-max-canon' of github.com:pexpect/pexpect into doc-and-test-max-canon
Two OSX fixes

- When echo=True, the full output is not received in this condition,
  strangely enough, its a buffer of exactly 1024, any more than that,
  no more bytes are received in the expect/select loop, even when
  specifying very large values of searchwindowsize= and maxread=.
  There is no reason for echo=True, we only rewrote the tests for
  echo output to debug unexpected travis-CI behaviour, which we
  could only find BEL on when echo was enabled, but this is not
  true for debian linux.
- When using os.fpathconf on stdout under py.test in OSX, we get
  OSError, stdin does not produce any such error, so use 0 instead
  of 1.