PyErr_SetExcFromWindowsErrWithFilename() decode the filename from the
filesystem encoding instead of UTF-8.

encoding instead of UTF-8.

encoding instead of UTF-8.

I've only tested regular runs and -j runs.  If I've broken anything
else I'm sure I'll hear about it sooner or later.

I'm assuming that the putative path from the malformed
pth file is simply not found and therefore ignored.

If a .pth file contained an error, it could cause a traceback in site.py,
terminating its processing.  In 2.7 and 3.2, the interpreter will then not
start.  Previously, a message would print saying to use -v to get the
traceback.  In either case, the traceback generated for a failed .pth file did
not include the .pth filename, making it difficult to debug the problem.  Now
site.py reports not only the .pth filename but also the line number causing the
error, and just skips the remainder of the file.

pipes (bug specific to Windows).

Improve also the unit test: write a portable unit test.

The RFC is bit hard to understand on this point, but the examples
clearly show that parameter values that are encoded according
to its charset/language rules don't have surrounding quotes, and
the ABNF does not allow for quotes.  So when we produce such
encoded values, we no longer add quotes.

New output looks like this:

Traceback (most recent call last):
  File "test.py", line 5, in test_ce
    self.assertCountEqual('abracadabra xx', 'simsalabim xx')
AssertionError: Element counts were not equal:
Expected 5, got 2:  'a'
Expected 2, got 1:  'b'
Expected 0, got 2:  'i'
Expected 0, got 2:  'm'
Expected 0, got 1:  'l'
Expected 0, got 2:  's'
Expected 1, got 0:  'c'
Expected 1, got 0:  'd'
Expected 2, got 0:  'r'

problem with Content-Length header and uncommenting the test.