Shim executables don't ensure termination of child processes

### What You Are Seeing?

Abrupt termination of a shim executable causes its child to be orphaned. The child becomes a daemon process.

Note that this doesn't apply to Ctrl+C from the CLI, which is treated differently by the terminal or OS. The problem occurs when the process is killed through any other method.

### What is Expected?

When a shim executable terminates for _any_ reason, all work should be stopped, i.e. the subprocess should terminate. It should either:

* Avoid spawning a subprocess.
* Use the job objects API, ensuring that when it terminates, its descendants terminate.

### How Did You Get This To Happen? (Steps to Reproduce)

This may happen due to programmatic termination of a shim process, or simply by clicking "End Process" in Task Manager or Process Explorer. Programmatic termination may happen in a build system that involves shelling out to various build tools such as `sass`. An error in one of the tasks may cause termination of the entire build, which may involve programmatic termination of immediate child processes, causing the orphan problem described above.

Start at the shim executable's child-process creation and termination paths, then review how Windows process termination behaves when the shim is killed outside Ctrl+C. Investigate the Windows Job Objects API as described in the issue and reproduce termination through Task Manager or Process Explorer. Done means descendants terminate when the shim ends without changing the stated Ctrl+C behavior.

Written by the indexing model from the issue text.