Win32 t/Unicode.t final test failing on cygwin

[tonycoz]

This seems similar to https://rt.cpan.org/Ticket/Display.html?id=103984

Since upgrading to cygwin 3.3.1 the perl CI has been failing this test:

$ ./perl harness -v ../cpan/Win32/t/Unicode.t
../cpan/Win32/t/Unicode.t ..
1..12
# Running under perl version 5.035006 for cygwin
# Current time local: Mon Dec  6 14:49:30 2021
# Current time GMT:   Mon Dec  6 03:49:30 2021
# Using Test.pm version 1.31
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok 7
ok 8
ok 9
# Test 10 got: <UNDEF> (t/Unicode.t at line 93)
not ok 10
#    Expected: "C:\\cygwin64\\home\\Tony\\dev\\perl\\git\\perl\\cpan\\Win32\\Foo \x{394}\x{419} Bar \x{5E7}\x{645} Baz"
#  t/Unicode.t line 93 is: ok(Win32::GetLongPathName($subdir), $long);
ok 11
ok 12
Failed 1/12 subtests

Test Summary Report
-------------------
../cpan/Win32/t/Unicode.t (Wstat: 0 Tests: 12 Failed: 1)
  Failed test:  10
Files=1, Tests=12,  0 wallclock secs ( 0.00 usr  0.02 sys +  0.05 cusr  0.06 csys =  0.12 CPU)
Result: FAIL

The underlying cause appears to be:

# cwd() also returns a usable ANSI directory name
my $subdir = cwd();

not behaving as the comment appears to expect, the name returned is the UTF-8 version of the wide character name, not the ANSI name.

While this was apparently triggered by a change in Cygwin, the behaviour in Cygwin itself here seems reasonable - returning the UTF-8 version of the path (just as Linux might when the system is using a UTF-8 locale and the user creates Unicode names).

See Perl/perl5#19239 for the perl tracking issue.

[jandubois]

I think the only sensible thing to do then is to skip this test on Cygwin. If cwd() doesn't return an ANSI short path, then there is no point in trying to convert it to the long form.

@tonycoz Please review #31 and let me know if you agree with it!