Allow wsl -u and default user specification in wsl.conf to use UIDs instead of usernames

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

This is related to #9649, where the inability of wsl -u and the default user specification to recognize users in the user database from sources other than `/etc/passwd` is concerned. Specifically, as I'm using `systemd-homed` to share my user home directory (NFS mounted) and user information between WSL instances and Linux machines, there is no entry for my username in the password file under WSL, although it is available to userdbctl, getpwnam, etc., and can be used to successfully log in using `/bin/login`, _ssh_, `machinectl shell username@.host`, etc., etc.

This prevents me from directly entering WSL as the default user, or using `wsl -u`.

**Describe the solution you'd like**

I would like to be able to use a uid, rather than username, with both the `wsl -u` switch and in the `/etc/wsl.conf` file; and I would like to be able to start programs, commands, etc., in WSL _regardless_ of whether a matching entry for that uid can be found in `/etc/passwd`. (While not usually terribly useful, starting programs with arbitrary UIDs is certainly possible under Linux.)

If WSL/systemd/etc. are already running and this option is used, this should become a de-facto non-arbitrary UID since its user record will be available from systemd-homed or other user information providers inside the distribution; if it is not, the UID specified will automatically become non-arbitrary as soon as the appropriate one of these starts up. It would be possible for a misconfiguration to leave a process running under an arbitrary UID, but such is trivially rectifiable.

**Describe alternatives you've considered**

At the moment, I have created an additional user

```
wsl:x:998:1000:WSL Startup User:/home/wsl:/bin/sh
```

which exists solely for the purpose of starting a WSL session, waiting for the full user database to be available, and then turning control over to the real user.

However, apart from being a somewhat baroque workaround and requiring a two-stage login process, this is far from a satisfactory solution as software (such as Visual Studio Code - see microsoft/vscode-remote-release#8052) expects to find you working under the WSL default user and need to access files for which the "WSL Startup User" has no permissions and can't readily gain access to via group permissions.

I am currently able to work around this specific example using Remote-SSH instead of Remote-WSL, and yet.

**Additional context**

None.

Start by reviewing the related issue #9649 and the entry points for the `wsl -u` option and the default user setting in `/etc/wsl.conf`. Define how UID-based startup should behave when no matching password entry is available, including interaction with user information providers and arbitrary UIDs. Done means both configuration paths accept UIDs and reliably start the requested process under that UID.

Written by the indexing model from the issue text.