Add shim command for launching hostprocess cntr processes

[dcantah]

Due to the rootfs for a hostprocess container being a bind mount that is
only viewable for a process currently running in the containers silo, this
poses some challenges for launching a process in the container image via
CreateProcess from outside of the container. There's no usermode mechanism
to join a job object/silo and then leave afterwards, so that isn't viable either.

How we were working around this fact today is by launching container processes
via cmd /c C:\hpc\mybinary.exe rest of the commandline. The reason this
works is because cmd exists outside of the bind mount and should always
exist, and then once cmd starts up it is able to view the bind mount as
it's running in the containers silo. We can get the same functionality
and keep full control of launching and managing the process by exposing a
new command on our shim that we can invoke instead.

This change adds in a new hidden hpc command to our shim that host process
containers will make use of. It looks for a file in its working directory
that contains all the info needed to launch and manage a container process.
This new shim instance will join the containers silo so it can successfully
see the rootfs (generally at C:\hpc) and launch processes. This also allows
us to get some backwards compatible behavior for how bind mounts are handled
on systems that bindflt isn't available. In addition to binding mounts to
the path requested, we can additionally bind them to a relative path under
the containers rootfs, which is what was done for non-bindflt machines.

In addition to this change I've added some safeguards around trying to kill
a process that has just recently exited and removed an unncessary environment
variable workaround from the initial process launch for a container.

[dcantah]

@kevpar Leaving this on draft as it builds on #1437 so I'll need to rebase after that gets in, but I'd love to get early feedback if possible. Edit: Sorry will add a description also soon

[dcantah]

@kevpar Okay, this is ready for review

[dcantah]

@marosset @jsturtevant fyi. This should get us backwards compatibility with mounts in beta

[helsaawy]

Do we care about pathological cases like \\?\C:\path\to\mount as well, or, worse yet, \\?\Volume{GUID}\path\?

[dcantah]

Turns out this actually won't work with nested paths, and my test cases were getting lucky as they built on each other (C:\foo, and C:\foo\bar). This change makes things really ugly right now also.. I think there's an easier way we can get backwards compatibility a lot easier that I'll push shortly. We can just use symlinks like we do now for mounts for backwards compat, and use bindflt for where the mounts are actually being asked to show up