Move EnC OOP - part 1

[tmat]

Moves EnC workspace service OOP.

The services that remain in-proc are ActiveStatementTrackingService and EditAndContinueDiagnosticAnalyzer. The former needs to be in-proc due to dependency on the editor tracking spans. Once the editor provides remote syncing capabilities we'll be able to move it OOP. The latter is a simple analyzer proxy that calls to OOP to perform the actual analysis. We'll be able to remove this once we move to diagnostic pull model.

EditAndContinueWorkspaceService is called via RemoteEditAndContinueServiceProxy. The proxy either calls the local service (if Roslyn runs w/o OOP) or serializes calls to RemoteEditAndContinueService, which in turn deserializes the inputs and calls remote instance of EditAndContinueWorkspaceService.

Fixes #42179

Includes #46826

Blocked on RPS regressions:

• #1229630(https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1229630): microsoft.servicehub.client.ni!Server.Dispose should not block
• #1226722(https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1226722): Avoid reporting telemetry in GlobalBrokeredServiceContainer.View.GetProxyAsync
• #1226692(https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1226692): Reduce StreamJsonRpc logging verbosity in RPS tests

Further possible improvements:

• Optimize allocations in AddLocalRpcMethod microsoft/vs-streamjsonrpc#575: Optimize allocations in AddLocalRpcMethod
• Replace usage of Newtonsoft.Json's CamelCaseNamingStrategy.ResolvePropertyName with more performant implementation microsoft/vs-streamjsonrpc#576: Replace usage of Newtonsoft.Json's CamelCaseNamingStrategy.ResolvePropertyName with more performant implementation

[tmat]

@sharwell Should should semi-work (other than tracking the active statements).

[davidwengier]

This makes sense, though its largely moving around bits of code I don't understand :D

[davidwengier]

It's a nit, because naming is hard, but I feel like Proxy is not ideal given the logic here and in other methods, and perhaps could be renamed in a follow up.

It feels like this class is the real EnC service, and using just the service on its own would be surprising because callers would have to know what extra work to do.

[tmat]

I don't think using the real service would be surprising because that service does not have any side-effects. It returns the diagnostics and the caller then is responsible for reporting them. The diagnostic handling here is just a workaround for not having pull diagnostics model and will go away once we remove solution crawler.

That said, I'm open to suggestions of a better name.

[tmat]

Superseded by #50410