Container engine interop

The Docker CLI is as close to a standard as exist in interoperating with container engines. This is why engines like [Podman](https://podman.io/) mirror the command line interface. The reference implementation of the dev container spec (#9) and things built up from it should generally support anything that mimics the Docker CLI since it intentionally does not directly talk to the engine's daemon as an abstraction. However, there have been subtle differences that have come up particularly around the areas of file mounting and permissions. Similar to #10, there's also been interest from communities using engines and CLIs like [Singularity](https://github.com/microsoft/vscode-remote-release/issues/3066), [nerdctl](https://github.com/microsoft/vscode-remote-release/issues/6014), [crictl](https://github.com/microsoft/vscode-remote-release/issues/6075), and even straight [kubectl](https://github.com/microsoft/vscode-remote-release/issues/12).

Today, the `runArgs` property is used heavily, and needs some abstraction for common properties (see #2). Any orchestrator support (see #10) would help in the case of more complex multi-container configurations. However, these do not resolve the simpler single container case where no orchestrator format is in-play.

To make it clear for how container engine communities could contribute support to the reference implementation or adopt the dev container spec in another form, I'd propose we:

1. Implement #2 and document how to add support for alternate engines in the reference implementation (#9)
2. Move `runArgs` to be an engine under a property much like `orchestrators` in #10 or `customizations` in #1 (e.g. `"docker" {"runArgs":""}` or `"docker.runArgs": ""`), with details on how to add other engine specific properties.