Allow setting wsl default user in the default nix config of the generated tarball

[jbury]

The docs actually already say this is possible 🤷

[jbury]

I'm not particularly knowledgeable on wsl - my initial "guess" as to what might be happening was that some agents might be loaded with an ancient/unpatched wsl.exe in one path, and another up-to-date one in another path, and inconsistently pick which to actually use for some reason.

My change to stop calling wsl --version, and instead just use Get-Command probably "fixes" the problem that's been making the pipelines fail sporadically, but not because Get-Command is actually a better command to use here. It's just because we're no longer calling wsl --version at all, which seems to have been most of the problem. Why? Not a damn clue. Unless there's some hidden configuration around the runners or their setup I'm not seeing in the .github dir, I'm not sure what more we can even do to investigate this specific bug.

I'm leaving Get-Command in regardless, because it's at least slightly more information about what we're running than removing the line entirely, but I'm happy to remove it entirely if folks want.

[jbury]

I'm adding the wsl --version call back in, mostly because I'm curious if it's got any more useful information for us.

[jbury]

@nzbr I'm not loving the flakiness of the pipeline tests even though I'm positive my change has nothing to do with the failures, but I don't think I should keep experimenting with fixes on this PR.

I think it's worth keeping the Get-Command invocation in the Setup WSL job just so we can see if we ever end up hitting a wsl binary at a path other than C:\Windows\system32\wsl.exe - but I think it'd be worth it to just split any further work on the pipeline stability into a new PR, and probably track it in an Issue.

Thoughts? Any feedback on the original change here?

[nzbr]

I'm merging this for now. If you find out more about the CI crashes, just make a new PR