Add a SplitPath unit test exercising Windows paths with drive letters

[nlebeck]

The goal of this PR is to test Windows-specific behavior that is working as intended for SplitPath.

There are some behaviors of the current implementation that this PR does not test. For example:

• A Windows path like "C:/dir/some_file.txt" parses fine on non-Windows platforms, with the same output.
• An invalid path like "C:/malformed_dir/:some_file.txt" parses fine on Windows, with the output path being "C:/malformed_dir/:".

I referenced this page to figure out what exactly qualifies as a valid Windows path: https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats.

[BhaaLseN]

I wonder if leaving the test empty is the way to go (vs. wrapping the whole test in the #ifdef instead).

[nlebeck]

I wonder if leaving the test empty is the way to go (vs. wrapping the whole test in the #ifdef instead).

I switched to wrapping the whole test in the #ifdef. (I'm not sure what the best convention is, and I don't have any preference.)

I also deleted and retyped the comment line that the linter was unhappy with. I couldn't see any difference in the diff, but maybe some unprintable character snuck in.

The OSX build failure on the latest version seems unrelated to this PR (dolphin.dmg: The timestamp service is not available.). But I don't know much about OSX development...

[JosJuice]

I also deleted and retyped the comment line that the linter was unhappy with. I couldn't see any difference in the diff, but maybe some unprintable character snuck in.

There was a trailing space.

[BhaaLseN]

The OSX build failure on the latest version seems unrelated to this PR (dolphin.dmg: The timestamp service is not available.). But I don't know much about OSX development...

That's an intermittent issue, nothing you need to worry about (for now).