Extend support for variables in `mount` syntax to include containerEnv, among others in devcontainer spec

[stewartadam]

The mount property in the devcontainer spec says it supports variables as defined in variables in devcontainer.json.

As best I can tell some of the spec is not implemented, for example containerEnv does not resolve.

There's also no way (that I found) to easily grab the connecting user nor their home directory (I was trying with ${containerEnv:HOME}), which would very nice for mounting volumes into ~/.foo for tool foo that persists user configuration we don't want destroyed each time the workspace is opened (e.g. ~/.azure, ~/.promptflow, etc).

[chrmarti]

containerEnv only becomes available once the container exists, but the mounts values are already needed to create the container.

We could change containerEnv to mean "image env" when the container does not exist yet or, maybe less ambiguous, introduce an ${imageEnv:...} expression to refer to environment variables on the image.