Why can't systemd environment have `WSLENV` or `WSL2_*` variables from `/init`?

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

While `WSLENV` is a great way to share environment variables from Windows to Linux shells, `systemd` processes don't inherit it nor any of the `WSL2_*` environment variables found in the parent /init environment (reflected in `/proc/2/environ` for example). A systemd unit that needs to read a file located in the Windows user profile folder cannot reliably due so because:
- the automount root is configurable, thus `/mnt/c/` root cannot be taken for granted;
- Linux processes don't know the Windows user name;
- Indirect methods leveraging `powershell.exe` and `cmd.exe` (such as `cmd.exe /C echo.%USERPROFILE%`) work sometimes:
- Interop may be disabled by config
- Windows hardening policies may prevent execution of binaries due lack of association between the user token and the systemd background process
- Similar hardening may even break `wslpath -aw /` (typically used to determine the WSL distro name) at the Plan9 driver level.

**Describe the solution you'd like**

I'd like to have either `WSLENV` effects propagated to `systemd` or include `WSL2_USER_PROFILE` and `WSL2_DISTRO_NAME` into the `systemd` environment block (see [src/linux/init/init.cpp:2434](https://github.com/microsoft/WSL/blob/8544b7b0b23163df3e05d08c5e822f088328c3d5/src/linux/init/init.cpp#L2434))

Should we agree on the preferred approach, I'd be happy to bring up a pull request implementing the necessary changes.

**Describe alternatives you've considered**

- Interested `systemd` units could attempt to read the pieces of information they need from `/proc/2/environ` but that's tedious, error-prone and perhaps unstable, especially if more than one unit needs that.
- Distributions could provide a `systemd` environment generator that reads from `/proc/2/environ` and propagates the pieces of information they consider necessary.

**Additional context**

On Ubuntu we leverage `cloud-init` as a way to perform automated provision of WSL instances. It works by reading the `#cloud-config` data from a specific location at the Windows user profile folder, which is simple and accessible. But for that it needs to know where that folder is as well as the name of the WSL distro instance being initialized. The current implementation relies on `cmd.exe /C echo.%USERPROFILE%` later translated with `wslpath`, but as explained above, certain corporate policies may interpret the attempt of launching `cmd.exe` as potential malware or at least unauthorized process launch attempt. Instead of asking those clients to relax their safeguards, I'd rather make cloud-init not depend on launching `cmd.exe` but reading environment variables directly instead.

Read src/linux/init/init.cpp around line 2434 and inspect how /init constructs the systemd environment; compare it with /proc/2/environ and the issue's WSLENV and WSL2_* examples. Confirm the preferred propagation approach with maintainers, then validate that a systemd unit can access the required variables without invoking cmd.exe or powershell.exe.

Written by the indexing model from the issue text.