Add support for debug attach in Test Explorer

[Evangelink]

          @evangelink The VS side is handling these RPCs, i.e. if you'd be debugging a test project and starting child processes, these should use the RPC calls back to VS.

What should happen on the MTP side is that:

1. When debugging a test, if the outer test runner starts an inner runner (for instance Fakes needs a child process with environment variables), this should happen via this RPC call. This was tricky to do given the existing MTP architecture and for most scenarios is not distinguishible from what we're currently doing.
2. If MTP has an equivalent of https://github.com/microsoft/vstest/blob/main/src/Microsoft.TestPlatform.ObjectModel/Adapter/Interfaces/IFrameworkHandle.cs#L30 it should be implemented via this RPC call. If we do not provide this functionality, we won't start the child processes under a debugger.

For the second one, if you'd point me to where the IFrameworkHandle is exposed in the bridge/adapter layers, we could handle it in a similar way to how we setup the output device here https://github.com/microsoft/testfx/blob/main/src/Platform/Microsoft.Testing.Platform/Hosts/ServerTestHost.cs#L476C1-L476C50.

Originally posted by @drognanar in #4865 (comment)

[nohwnd]

fyi there is also this iframeworkhandle2, which is currently the preferred way to attach debugger to processes in vstest. but imho it does not have advantages over the original apart from forcing the process to have to wait for the debugger to attach (somehow). If there should be a proper support for attaching to processes that goes in this direction, we should at least provide more info to the debugger, e.g. what engine to use to attach to the child process (e.g. .net core).

https://github.com/microsoft/vstest/blob/main/src/Microsoft.TestPlatform.ObjectModel/Adapter/Interfaces/IFrameworkHandle2.cs#L16

those two mechanisms are also mutually exclusive.