Bring "attach config" devcontainer.json subset into spec

[Chuxel]

While not as full featured as the full devcontainer.json flow, the attach configuration flow is useful for scenarios where you already have a running container you want to interact with. To recap, this allows is a subset of devcontainer.json properties to be applied to an already running container. The idea is that tools "attach" to a container that were spun up in some way while still taking advantage of some of the capabilities that the metadata in the dev container spec enables. The current list of properties can be found here (tho some would move under customizations per #1).

This subset (customizations aside) could also represent the minimum bar for when something would be said to support the spec. These properties are also very compatible with the idea of using labels to store metadata (#18), particularly if this expanded to also support labels on containers in addition to images, so file-based representation would be only one form.

With this in mind, we could refer to this as a "minimal profile" of dev container properties (verses "full profile"). This subset of properties should also work with any orchestrator (related to #10) since they can all be applied at runtime which further highlights the value of bringing the idea into the spec. That said, despite naming, it likely makes sense to have a separate schema with this subset to aid use.

More complex capabilities like features would not part of this configuration, though should we move forward with label-based metadata (#18), there's no reason you couldn't pre-build an image, reference it, and then use this minimal profile for anything else that is needed.

[Chuxel]

This appears to be the current list of properties that could be supported in an attach config subset:

• name
• forwardPorts
• portsAttributes
• otherPortsAttributes
• remoteEnv
• remoteUser
• userEnvProbe
• customizations <= Tool/service would need to define which would work.
  • vscode.extensions
  • vscode.settings
• postAttachCommand

The following could be layered in with a subtle tweak to their triggers. Specifically, we could say these can be triggered at the first point that a dev container service or tool connects, and that waitFor is more of a statement as to when the end-user is able to start making edits. Several of these already use marker files to indicate if they've been triggered already which would continue to function.

• onCreateCommand
• updateContentCommand
• postCreateCommand
• postStartCommand
• waitFor

Of these, postStartCommand would be the hardest since it would require inspecting the container to see when it was started and then tracking the last recorded start time as a file in the container.

While most of the properties in #2 would not work in this context since they assume control of container config with one possible exception.

• entrypoint

This could supported as something that runs as the container's user rather than remoteUser and otherwise ends up being like postStartCommand. However, the challenge is that this would not run as PID 0, so that would have to be a documented limitation.

For Features, if the image used for the container included properties from #18, supported properties above would be applied, but no direct features property would be possible since this can affect the image build.