[win]: Fix rel2abs handling of long path prefixes

[ugexe]

The previous behavior did not generate correct absolute paths for UNC paths (like \\\\UNC\\share\\C:\\foo\\bar.txt) or long/raw paths (like \\\\?\\C:\\foo\\bar.txt) due to the way the rel2abs method decides when a path is relative and thus needs to be transformed. This updates the windows version of rel2abs to check for absoluteness using .is-absolute, which allows one to get the expected results when using an e.g. long path like IO::Path.new(q|\\\\?\\C:\\foo\\bar.txt|).IO.e

[ugexe]

It's really hard for me to grok or understand what is intended to happen with all the nqp being used in combination with the various regex (instead of one or the other). The examples below show what this specific change is intended to fix, although I'm not sure what other ramifications this change may have:

# Actual (without this PR)
PS C:\rakubrew\versions\moar-2023.02\foo> raku -e 'say IO::Path.new(q|\\\\?\\C:\\foo\\bar.txt|).absolute'
C:\?\C:\foo\bar.txt

# Expected (with this PR)
PS C:\rakubrew\versions\moar-2023.02\foo> raku -e 'say IO::Path.new(q|\\\\?\\C:\\foo\\bar.txt|).absolute'
\\?\C:\foo\bar.txt

[ugexe]

This also allows me to do say "\\\\?\\C:\\$really-long-path".IO.e on Windows and have it return True instead of False

[ugexe]

This passes one TODO roast test, but fails one other one. I'm investigating why.

[ugexe]

So I suspect IO::Spec::Win32.is-absolute may need to be updated. The test that fails is IO::Spec::Win32.rel2abs("\\foo", "C:/a") which gives C:/foo (which I believe to be correct) before this PR and \foo after this PR. This seems to be related toIO::Spec::Win32.is-absolute treats a leading slash as an absolute path, but in reality \foo is a path relative to the cwd volume. This PR uses self.is-absolute to fix a different issue, and that worked because the long path prefix of \\?\ starts with a slash, but in reality self.is-absolute should probably be a little smarter about determining what is absolute.