The command will be executed before requests and before configuring SSH to set custom headers.

Some notes:

1. When I use--header I seem to get the value set twice. For example if I usecoder --header X-MY-CUSTOM-HEADER=hello-there then on the server end I seex-my-custom-header: hello-there, hello-there so we should look into that.
2. I went with environment variables to pass data to the credentials process for now since I figured that would be easier than parsing command-line arguments but opinions are welcome here. OnlyCODER_URL right now. Are there others needed?
3. More importantly, I am not sure about the config SSH portion. Since configuration might only happen on the first connect, the headers we hardcode into the SSH config could expire.

I have two main ideas for fixing the SSH config issue:

1. Modify the CLI to call out to the same process to get the headers.--credentials-process or something like that. The CLI executes the process just as the extension does and sets the headers. We set--credentials-process in the SSH config on the plugin side and are off to the races.
2. Add a second VS Code setting for a proxy command wrapper which gets passed the path to the Coder binary and is responsible for adding the appropriate--header flags and passing through any other flags. This way this credential process is called every time SSH is invoked. Or instead of a separate setting it could be an environment variable/flag and we reuse the same process; it can switch behavior depending on what task it needs to do (output JSON or execute the Coder binary).

An example of the second option:ProxyCommand my-wrapper --wrapper-flags -- --coder-flags wheremy-wrapper is essentiallyexec $CODER_BINARY --header my-custom-header "$@" except everything after-- should get passed through to the Coder binary and the rest can be flags to the wrapper itself in case we need them.

Thoughts? I am inclined to go the first route since the second requires more complexity on the user side but the second does at least have the advantage (or danger) of allowing more control over how the Coder binary executes.

I also considered substitution in the proxy command (something similar tocoder $(/path/to/credentials-process) ssh dev.dev --stdio) but I am not sure that is portable.

Sorted the above,--header-command has been added to the CLI although we will need the next release before this can be used in the plugin.

Closes#76 and supersedes#81.