+ No WindowsError exception.
+ Add `test_exc.py` for unicode issues.
+ Single-arg for decoding-streams in pump-func.

+ CAUSE: In Windows, Diffs freeze while reading Popen streams,
probably buffers smaller; good-thin(TM) in this case because reading a
Popen-proc from the launching-thread freezes GIL.  The alternative to
use `proc.communicate()` also relies on big buffers.
+ SOLUTION: Use `cmd.handle_process_output()` to consume Diff-proc
streams.
+ Retroffited `handle_process_output()` code to support also
byte-streams, both Threading(Windows) and Select/Poll (Posix) paths
updated.

- TODO: Unfortunately, `Diff._index_from_patch_format()` still slurps
input; need to re-phrase header-regexes linewise to resolve it.

That way, we do not have to figure the change type out by
examining the diff object.

It's implemented in a way that should yield more desireable results
as we keep the change-type that git is providing us with.

Fixes #493

Previously, the following fields on Diff instances were assumed to be
passed in as unicode strings:

  - `a_path`
  - `b_path`
  - `rename_from`
  - `rename_to`

However, since Git natively records paths as bytes, these may
potentially not have a valid unicode representation.

This patch changes the Diff instance to instead take the following
equivalent fields that should be raw bytes instead:

  - `a_rawpath`
  - `b_rawpath`
  - `raw_rename_from`
  - `raw_rename_to`

NOTE ON BACKWARD COMPATIBILITY:
The original `a_path`, `b_path`, etc. fields are still available as
properties (rather than slots).  These properties now dynamically decode
the raw bytes into a unicode string (performing the potentially
destructive operation of replacing invalid unicode chars by "�"'s).
This means that all code using Diffs should remain backward compatible.
The only exception is when people would manually construct Diff
instances by calling the constructor directly, in which case they should
now pass in bytes rather than unicode strings.

See also the discussion on
https://github.com/gitpython-developers/GitPython/pull/467

The diff --patch parser was missing some edge case where Git would
encode non-ASCII chars in path names as octals, but these weren't
decoded properly.

    \360\237\222\251.txt

Decoded via utf-8, that will return:

    💩.txt

Fixes #426

Specifically "string_escape" does not exist as an encoding anymore.

This specifically covers the cases where unsafe chars occur in path
names, and git-diff -p will escape those.

From the git-diff-tree manpage:

> 3. TAB, LF, double quote and backslash characters in pathnames are
>    represented as \t, \n, \" and \\, respectively. If there is need
>    for such substitution then the whole pathname is put in double
>    quotes.

This patch checks whether or not this has happened and will unescape
those paths accordingly.

One thing to note here is that, depending on the position in the patch
format, those paths may be prefixed with an a/ or b/.  I've specifically
made sure to never interpret a path that actually starts with a/ or b/
incorrectly.

Example of that subtlety below.  Here, the actual file path is
"b/normal".  On the diff file that gets encoded as "b/b/normal".

     diff --git a/b/normal b/b/normal
     new file mode 100644
     index 0000000000000000000000000000000000000000..eaf5f7510320b6a327fb308379de2f94d8859a54
     --- /dev/null
     +++ b/b/normal
     @@ -0,0 +1 @@
     +dummy content

Here, we prefer the "---" and "+++" lines' values.  Note that these
paths start with a/ or b/.  The only exception is the value "/dev/null",
which is handled as a special case.

Suppose now the file gets moved "b/moved", the output of that diff would
then be this:

     diff --git a/b/normal b/b/moved
     similarity index 100%
     rename from b/normal
     rename to b/moved

We prefer the "rename" lines' values in this case (the "diff" line is
always a last resort).  Take note that those lines are not prefixed with
a/ or b/, but the ones in the "diff" line are (just like the ones in
"---" or "+++" lines).

When both old/new mode and rename from/to lines are found, they will
appear in different order.