Fix a hang of SSH pull on Windows.

The method GitClient._handle_upload_pack_head() could hang when it repeatedly
called write_pkt_line() and didn't call read_pkt_line() in between. This would
cause the output buffer to fill up when the server didn't accept any more input
since it was waiting for the client to consume its output.

This situation was caused because SubprocessWrapper.can_read() was always
returning false! The method is implemented by calling PeekNamedPipe() and
comparing the "lpBytesLeftThisMessage" value against zero. MSDN says:

    lpBytesLeftThisMessage [out, optional]

    A pointer to a variable that receives the number of bytes remaining in this
    message. This parameter will be zero for byte-type named pipes or for
    anonymous pipes. This parameter can be NULL if no data is to be read.

Since the code is used only with byte-type anonymous pipes, this function is
documented to always return zero in this parameter.

This bug was introduced in commit d118a8fa1d9203a964ab807bfb4d3c6e311a7c9c:

    date:        Fri Jul 01 16:26:01 2011 +0200
    user:        Jelmer Vernooij <jelmer@samba.org>
    summary:     Fix use of SubprocessWrapper on Windows.

The fix is to use the return value of lpTotalBytesAvail:

    lpTotalBytesAvail [out, optional]

    A pointer to a variable that receives the total number of bytes available to
    be read from the pipe. This parameter can be NULL if no data is to be read.

dulwich/client.py

@@ -616,7 +616,8 @@ class SubprocessWrapper(object):
             from msvcrt import get_osfhandle
             from win32pipe import PeekNamedPipe
             handle = get_osfhandle(self.proc.stdout.fileno())
-            return PeekNamedPipe(handle, 0)[2] != 0
+            data, total_bytes_avail, msg_bytes_left = PeekNamedPipe(handle, 0)
+            return total_bytes_avail != 0
         else:
             return _fileno_can_read(self.proc.stdout.fileno())