"Fix" this test on Win32 by suppressing tests of error handling that relies on proper...

"Fix" this test on Win32 by suppressing tests of error handling that relies on proper error detection within archive_entry_update_pathname_utf8().

The core problem here is that Windows has several different APIs for character-set conversion.  These tests rely on the POSIX-standard setlocale() to set the default character set for this process in order to then force character-conversion failures and verify the error-handling.  But the Win32 APIs don't obey setlocale() so this fails.  Indeed, I've found no way to programmatically override the CP_ACP code page for just the current process:  I considered using CP_THREAD_ACP instead but it seems to be broken (or at least there are a lot of bloggers claiming it should never be used).  It doesn't help that Windows documentation confuses "code page" with "language" (SetCurrentLocale() accepts a language code but the documentation claims it sets the code page while offering no insight into how language codes get mapped to code pages---remember that Japanese and Chinese are supported by several code pages).  I've gleaned from various blogs that the default code page cannot be set to UTF-8 in any case due to some bad assumptions deep in Win32's character-conversion routines (this implies, of course, that there is a way to set the default code page, which I've not been able to find).  From this, it appears that it's simply not possible to do the kind of testing I want to do here; if someone knows otherwise, please let me know.

SVN-Revision: 1681