Fix multi-byte delimiters split across read buffers - #1854

Fixes tqdm#1847.

posix_pipe searched only the fresh chunk from each read:

    i = tmp.find(delim)

When the delimiter is multi-byte and --buf_size is smaller than it, the
delimiter's bytes land in two consecutive reads, so neither chunk contains it.
The saved prefix is then appended without ever being searched, and the
delimiter is missed.

Searching buf + tmp finds it, and because buf is non-empty in exactly the case
that matters, the indices have to refer to the concatenation:

    combined = buf + tmp
    i = combined.find(delim)
    if i < 0:
        buf = combined
        break
    fp_write(combined[:i + len_delim])
    callback(1 if callback_len else combined[:i])
    buf = b''
    tmp = combined[i + len_delim:]

Note that the record passed to the callback must also come from combined, and
the leftover chunk is combined[i + len_delim:]. Using tmp[i + len_delim:] would
silently drop the bytes still sitting in buf, which is what a partial fix that
only changes the find() does.

Verified against a 2-byte delimiter at --buf_size 1, 2, 3, 4, 5, 7 and 64:

  before: 2it instead of 3it, and --update died with
          SyntaxError: invalid syntax, because the first delimiter byte leaked
          into the record and left literal_eval parsing '1\xc3\xa92'
  after:  3it in counting mode, 6it with --update, at every buffer size

The stdout payload is byte-for-byte unchanged, and single-byte delimiters are
unaffected since they cannot straddle a boundary.

New test tests_main_delim_multibyte_split covers the counting and --update
paths at three buffer sizes and asserts the payload is preserved. Reverting
cli.py makes it fail with 2it.

The full suite passes: 174 passed, 5 skipped (numpy, dask and keras are not
installed here).