Introduce support for auto-creation of user referenced in remoteUser or containerUser properties

This proposal is an offshoot of discussions related to refactoring the "[common script](https://github.com/microsoft/vscode-dev-containers/blob/main/script-library/common-debian.sh)" currently housed in the microsoft/vscode-dev-containers repository.

A frequent area of confusion for dev containers is how to create a non-root user for a container. In addition, developers will sometimes add a `containerUser` or `remoteUser` property to their devcontainer.json and expect it to be created.

This led to the `common` script and all related images built out of the vscode-dev-containers repository having the logic to add a non-root user built into it. Overall, this has worked pretty well. However, Dev Container Features (#61) also need to adapt to the presence of a non-root user to set permissions. Existing Features in the vscode-dev-containers repository include automated logic to [attempt to auto-detect a non-root user](https://github.com/microsoft/vscode-dev-containers/blob/main/script-library/go-debian.sh#L35-L61). But the process has the potential to not detect correctly and it increases the complexity of each. Furthermore, it also means that the common script always needs to fire first in the Feature build order - which is not ideal.

All of this indicates that we should consider user generation a core part of the dev container spec. There are three things here:

1. Create a user if one with the specified name does not exist
2. Optionally install and configure `sudo` for the user
3. Optionally set up `sudo` to not require a password for the user ("passwordless")

To support all three of these, we can support an object syntax in addition to the current string format. E.g.,

```jsonc
{
"remoteUser": {
"name": "devcontainer"
"create": true,
"sudo": "password" // Other options are "none", "passwordless"
}
}
```

The existing string format would default to the above values:

```json
{
"remoteUser": "devcontainer"
}
```

We could use "passwordless" as the sudo default, but it likely makes sense to stick with a secure default here given the new semantics. Sudo could be installed by default, but the user would need to set a password to start using it in this case.

In addition, Dev Container Features should have an environment variable passed into them with the value of `containerUser` and `remoteUser` so that they can adapt without their own detection logic.

```
CONTAINER_USER=root
REMOTE_USER=devcontainer
```

We could also consider expanding https://github.com/devcontainers/spec/issues/25 into the user create scenario as a way to fire scripts to update things like permissions when this user is created.

//cc @alexdima @chrmarti @jkeech @samruddhikhandale @joshspicer