Implement reparenting ScopedContextKeyServices

[roblourens]

Background: #99318

The notebook editor has to be reused when dragging it between editor groups because we can't lose the state of code running in outputs in the webview. This has been implemented since a few months ago but there is an issue - the ScopedContextKeyServices under the notebook editor (like for the ListView) are created as children of the context key service for the editor group. This causes issues unless they can be reparented to the context key service for the correct group.

I wanted to fix this by persisting only the webview and reinstantiating the notebook editor itself so that this would work more like other editors (where we always reinstantiate the edit when moving it between groups). We can't do that because the webview has to be in the DOM in the middle of the notebook editor DOM structure. If you move it in the DOM, its contents will reload.

I believe the only solution is to allow moving ScopedContextKeyServices to a new parent. This is a little awkward but I think it's unavoidable. So this PR does the following

Implement reparenting ScopedContextKeyServices

updateParent has to do the following

• Update this._parent
• Get the Context, and the parent's Context, update the Context's this._parent. This requires exposing the ID which I don't really like
• Collect all context values before and after, diff them, fire updates for any changes

Give NotebookEditorWidget its own ScopedContextKeyService

Because we need one root for the editor to move to the new parent.

Give the title control a way to get the context key service inside any editor, not just code editors

We had a backdoor in place just for the code editor, but we can extend this to any editor. We could do this in a nicer and less ad-hoc way than what I've implemented here @bpasero, like with a method on BaseEditor to override, let me know what you think.

[jrieken]

adding @alexdima who did the context key services

[bpasero]

I don't really like the new indirection via getEditorWithContext and I also do not like our current use of getCodeEditor which makes this code work only with ICodeEditor or IDiffEditor. Rather I think every workbench editor should have a chance to implement this properly and then do the right thing internally.

As such I would suggest to expose a method from all base workbench editors that subclasses can override to control this and we keep the current behaviour inside the text editor.

We also carefully need to check other places where we call invokeWithinContext. For example, there is IEditorService#invokeWithinEditorContext which probably needs the same tweak.

[roblourens]

Good point. Should this be on IEditorPane or IEditorControl?

[bpasero]

@roblourens I feel like it should be on IEditorPane because that is the workbench concept for editors. The control is mainly a way to get at the ICodeEditor in most cases but I think in this case is not needed (the implementation can delegate as needed).

[alexdima]

👍 The changes in the context key service look good!