spawn the agent in a process group / job

[bmc-msft]

When we terminate the agent, any child processes it's created do not get
terminated but should.

By launching in a process group (or job) using the command-group crate,
we can terminate the child and all of it's children automatically.

[bmc-msft]

Note, on Windows, command-group uses a job object created with winapi::um::jobapi2::CreateJobObjectW with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE set. On kill, the job object is terminated, which should kill all of the children (and grand children).

[bmc-msft]

All of the windows tasks are failing during integration testing. Investigating.

[bmc-msft]

This PR pins to the commit hash associated with a PR that addresses handling timeouts to GetQueuedCompletionStatus.

watchexec/command-group#3

Once this PR, or something like it, has been merged & released, we should move to the released version of command-group.

[ranweiler]

This overall approach seems reasonable, at least as a short-term improvement.

I guess I'd then ask:

1. Should we being using this for every child process, or at least many others?
2. I wouldn't think that the temp dir bug in the onefuzz-agent should be impacted by this at all. In particular, if the supervisor is "done", or knows that it is stopping, it should never be possible for a the onefuzz-agent to cause a task failure, period. Furthermore, if a supervisor is running task A, and we tell it to stop because task A should be stopped, this should already be reflected in the server, and I'd expect any subsequent "task A failed" messages should just be dropped as spurious. If that's not happening, there's a deeper problem we should also be fixing.

An aside, in terms of merging: we should split the process group changes out from the unrelated addition of all the extra context() calls.

[stishkin]

Closing.

Will revisit some time later