make: normalize backslashes in env-imported variable values

[Peter0x44]

On Windows, the VULKAN_SDK environment variable, as set by the Vulkan SDK qt ifw installer contain backslash-separated paths. When GNU Make expands these into recipe lines passed to a unixy shell, the backslashes make it over to the shell command, where they are treated as escape characters, mangling the paths.

As a result, using make -f llama.mak would fail to build, if invoked from powershell, on a system with the vulkan SDK installed.

Normalize backslashes to forward slashes in all variable values imported from the Windows environment at startup, when a "unixy" shell is being used. This is the same thing that BusyBox-w32 ash does in setwinxp() on shell startup.

[Peter0x44]

I've found powershell to be quite useful for running agents, so I noticed this issue when I went to build llama.mak. I figured it would be sensible to do the same change busybox-w32 does to the environment variables expanded into recipes when SHELL is "unixy". But I'm a little unsure if it could have other consequences, so opened as a PR instead of pushing it.

[skeeto]

But I'm a little unsure if it could have other consequences, so opened as a PR instead of pushing it.

I appreciate it. I too am a little worried about edge cases a dumb conversion might break. The conversion in busybox-w32 breaks some things (which is why we need etc/profile), but there's no precedent of it not breaking these things. We'll merge this after the GCC 16 release and let it "cook" for awhile on master. Try to exercise some builds with GNU Make, perhaps even by using -G 'MinGW Makefiles' (what an awful name) in CMake.

[Peter0x44]

This shouldn't affect -G "MinGW Makefiles" because it uses SHELL=cmd (you can see this in the generated makefiles)
It could affect Unix Makefiles, which do work under BusyBox-w32