Provide a means of obtaining WSL version information from inside WSL instance

[cerebrate]

Is your feature request related to a problem? Please describe.

For those few applications which operate inside WSL instances knowing that they're running under WSL, it's useful to know which version of WSL they're running under, and thus understand which features are available and which behavior to expect. I have noticed this most recently with the changes between 0.67.6 and 0.68.4 requiring changes in various systemd units and associated scripts shipped as part of bottle-imp, but it has also come up in the past and undoubtedly will in the future.

Describe the solution you'd like
Ideally, the same information provided by wsl --version, i.e.:

WSL version: 0.68.4.0
Kernel version: 5.15.68.1
WSLg version: 1.0.44
MSRDC version: 1.2.3401
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22000.978

could be provided inside WSL in file format, similar to the way in which WSLg provides version information in the /mnt/wslg/versions.txt file. Perhaps /run/WSL/versions.txt?

Describe alternatives you've considered

In some cases, it is possible to acquire this information simply by running wsl.exe --version via Windows interoperability and parsing the output, but this requires both that Windows interoperability be enabled, and that it be available at the needed time (for instance, it is not accessible during early systemd startup when systemd is enabled). As such, it's not a general solution to the issue.

[Biswa96]

changes in various systemd units and associated scripts shipped as part of bottle-imp

Do you want to check if systemd container feature is enabled or not? AFAIK, WSL does not change any files in user distribution.

[cerebrate]

@Biswa96 No, that's easy to detect from inside the distribution, as it's entirely inside the distribution.

In that particular case, I was thinking of the change in user runtime directory handling between 0.67 and 0.68. Under 0.67, WSL doesn't touch the user runtime directory, meaning that bottle-imp needs to bind mount /mnt/wslg/runtime-dir over /run/user/1000 (and only for user 1000) for everything to work properly with systemd user sessions (this is the long-time genie behavior); under 0.68, contrariwise, WSL does this bind mount automatically, so instead bottle-imp needs to prevent systemd from automatically creating and clearing the user runtime directory otherwise it breaks WSLg (issue #8918).

I should note that I'm using this just as an example, as there are various other changes I've needed to make as WSL has evolved over its life; and while there are various ways to detect some of these behaviors other than getting the WSL version, a single place to check - say, /run/WSL/versions.txt - would be much better than a dozen ugly hacks.

[cerebrate]

This would rather depend on having #8996 fixed first so that credentials are available to systemd, but it might be useful to pass the WSL version to the systemd instance (when enabled) as a credential, using the passed-through command-line option

systemd.set-credential=wsl.version:0.70.5.0

for example, which would make it available to the WSL instance in a way that would make it particularly easy to condition anything WSL-specific on its presence and version.

[cerebrate]

While I'm at it, it would also be very useful to have %SystemRoot% passed to WSL in the same way, for the benefit of those WSL utilities that need to call basic system utilities without (preferably) introducing a dependency on cloning the Windows path into WSL.