Initial implementation of a new 'lightweight' background-work-indicator that we can use in-situ in the editor.

[CyrusNajmabadi]

Followup to #59802

The model of this closely follows (including at the API level) the IUIThreadOperationContext model the editor already has for CommandExecutionContexts.

Namely, an operation (like goto-def, add-using-on-paste, etc.) can startup and create such a context object to represent the work they do. However, instead of that context object being backed by a threaded-wait-dialog (TWD) (modal, heavyweight, focus-stealing), they instead get one effectively backed by a rich tooltip (non-modal, lightweight, doesn't affect focus) in the code where they started the operation. The UI for thsi tooltip is still a work in progress. However, you can imagine it saying things like Navigating to definition (Esc to cancel) with the options for things like progress to be shown using a thin progress-spinner like we have in many other parts of the IDE.

Clients of hte IUIThreadOperationContext can treat it just like they would a TWD, adding scopes to it and setting the description/progress of sub-scopes. The tooltip will then batch up those changes and update the UI accordingly.

The indicator also tries to come with some batteries included. For example, it automatically hooks up to Esc being listened to to cancel the work it is doing. It can also auto-cancel on edits to the buffer (the default), or navigating away from taht doc (the default).

Looks like this:

[CyrusNajmabadi]

Tagging @cdblake1

[davidwengier]

Why turn this off, and handle cancelOnEdit ourselves? Is it just not working yet?

[CyrusNajmabadi]

Primarily because when we handle it ourselves we go through our entire pipeline of steps (including cancel'ing the CTS for our operation). We don't have an effective way (that i could tell) to know that the tooltip was dismissed due to buffer change.

[davidwengier]

I thought I remember seeing something on the spec, either an event, or a cancellation token that we could use (and created linked token from), but if not, then fair enough. I might have been looking at the V2 doc.

[sharwell]

Integration tests showed a bunch of errors coming from this exception:

SetSite failed for package [IntegrationTestServicePackage]Source: 'Microsoft.VisualStudio.IntegrationTest.Setup' Description: Method not found: 'Microsoft.VisualStudio.Threading.JoinableTaskFactory Microsoft.VisualStudio.Shell.AsyncPackage.get_JoinableTaskFactory()'.
System.MissingMethodException: Method not found: 'Microsoft.VisualStudio.Threading.JoinableTaskFactory Microsoft.VisualStudio.Shell.AsyncPackage.get_JoinableTaskFactory()'.
   at Microsoft.VisualStudio.IntegrationTest.Setup.IntegrationTestServicePackage.<InitializeAsync>d__1.MoveNext()
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at Microsoft.VisualStudio.IntegrationTest.Setup.IntegrationTestServicePackage.InitializeAsync(CancellationToken cancellationToken, IProgress`1 progress)
   at Microsoft.VisualStudio.Shell.AsyncPackage.<>c__DisplayClass20_0.<<Microsoft-VisualStudio-Shell-Interop-IAsyncLoadablePackageInitialize-Initialize>b__1>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Threading.JoinableTask.<JoinAsync>d__76.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Microsoft.VisualStudio.Services.VsTask.RethrowException(AggregateException e)
   at Microsoft.VisualStudio.Services.VsTask.InternalGetResult(Boolean ignoreUIThreadCheck)

I'm guessing this PR updated dependencies to versions not supported by CI?