Move pickProcess to file-based discovery

[mattchenderson]

Sometimes, early breakpoints for .NET Functions projects (e.g., in Program.cs) are missed in debug sessions. This is due to the way the existing pickProcess function works.

VSC will poll the host process spun up by Core Tools waiting for a desired response from the status endpoint, which would happen after worker start. It then scans the process tree to get the deepest child process (which is itself somewhat fragile). As a result, some amount of execution of the worker occurs prior to attach.

The Core Tools has a --dotnet-isolated-debug flag which will cause the process to wait super early, only to proceed once a debugger is attached. You can add this to the Core Tools start task in tasks.json, but this wait occurs before the status endpoint would return, so you'll just hit timeouts.

We take an alternative approach in Visual Studio. The launch includes --dotnet-isolated-debug as well as --enable-json-output --json-output-file <tempFile>. With this configuration, before the worker starts its wait, it will write out a JSON payload to the temp file, noting its process ID. Here is an example taken from a recent run:

{ "name":"dotnet-worker-startup", "workerProcessId" : 32496 }

The component that launches the Core Tools process can decide on the specific location and then watch for it to be updated. This ensures that it can get the information, but that the customer code isn't engaged until the debugger is present, allowing early breakpoints to be hit. We should use this model for Visual Studio Code.