Fix multiple-initialization on crash recovery - Client creation needs refactoring

The process of creating client/languageClient objects when the extension initializes, or recovers from a crash, is not well managed/synchronized. There is a mixture of async code and sync code (that kicks off async code without waiting for it).

Currently, there is a bug where, if the process of recovering from a crash is interrupted with another crash (in the LSP initialization message) or a transient failure to execute the process, two crash recoveries will run simultaneously, resulting in multiple initializations of the same cpptools process.

Although we can move sync code out of constructors (for DefaultClient, etc.) and into async init functions fairly simply, so we can await stuff, that incurs possible deadlocks (perhaps in combination with the enqueue chain, which is client-specific), making this not a trivial fix.

Trace extension initialization and crash recovery through the constructors for DefaultClient and related client/languageClient creation, then examine the client-specific enqueue chain and LSP initialization message. Identify where concurrent recovery can overlap and where synchronous code starts asynchronous work. Done means interrupted recovery cannot trigger multiple initializations of the same cpptools process without introducing deadlocks.