Use SHGetKnownFolderPath instead of SHGetFolderPathA

[timangus]

As title. ShGetFolderPathA is an ancient API that we are using to retrieve "special" folder locations on Windows, which is old and crusty and we should stop using it. Here I replace it with SHGetKnownFolderPath.

Pros:

• It's not old and crusty
• It doesn't require any nonsense to compile with MSVC
• It doesn't require ludicrous shenanigans to access like dynamically loading a library at runtime
• According to the documentation, we're effectively calling it anyway; might as well cut out the middle man

Cons:

• Minimum supported OS goes from XP to Vista
• It's wide string only, so we must convert its results for Q3's purposes

[GirianSeed]

It doesn't require any nonsense to compile with MSVC
It doesn't require ludicrous shenanigans to access like dynamically loading a library at runtime

SHGetFolderPathA doesn't need to be called via LoadLibrary/GetProcAddress. We can add either -lshell32 or -lshfolder to the LDFLAGS to allow it to be called directly. The inclusion of shfolder.h can be removed to satisfy MSVC since shlobj.h also prototypes SHGetFolderPathA/W anyway.

I only included shfolder.h in my original PR to avoid having to copy-paste or declare an custom function pointer type for SHGetFolderPathA. I should have paid more attention to the fact my MSVC installation didn't have that header, but I was only focusing on fixing the build error in GCC and trying to change as few lines of code as possible.

[timangus]

Well yes I'm conflating things a bit here. If I could be bothered I'd look it up, but my recollection is the dynamic loading was do to with supporting older OSes. Nevertheless it's an API that's been deprecated for a long time and it makes very little sense to keep using it.

[zturtleman]

Personally, I would like to see XP continue to work. SDL3 dynamically loads SHGetKnownFolderPath but otherwise falls back to SHGetFolderPathW. Perhaps ioquake3 could do similar?

[timangus]

Replaced by #744