add support for workerBinary configuration

Describe the enhancement
With self-hosted runners all jobs usually have full access to the runner
directory. You can put the runner in a VM or container and use --once to
restart with a clean environment after each job but that doesn't prevent jobs
from doing either of the following:

• access runner secrets like .credentials_rsaparams to then take over the
  runner
• modify the listener to nuke --once and manipulate future jobs.

To fix that issue I'm running Runner.Listener in the host environment while
running Runner.Worker in a VM or container.
That is easily possible because the only way of communication between the two
are unnamed pipes which can easily be forwarded into another environment.

In my specific setup I set the config workerBinary to an absolute path outside
of the runner installation. That binary then starts a qemu VM, forwards the
pipes into it, places a copy of the runner installation into the VM and starts
Runner.Worker with the forwarded pipes as the arguments.

Additional information
https://github.com/actions/runner/pull/1122

Start by reviewing the Runner.Listener and Runner.Worker communication described in the issue, then read pull request #1122 for the proposed workerBinary behavior. Done means the runner supports configuring an absolute worker binary path so the listener can launch Runner.Worker externally while preserving the unnamed-pipe arguments.