Fix Highlighting in SCM Tree

[colin-grant-work]

What it does

This PR fixes #8581 by adjusting the ScmTreeLabelProvider class to provide labels for all of the ScmTreeWidget node types and then using the searchHighlights map to produce a highlighted caption. This introduces adjustments to the interfaces of the various ScmTreeWidget node types, but those could be made non-breaking by adding | ReactNode to the previous specifications, if that is desirable.

How to test

1. start the application in a source-controlled workspace
2. perform changes and open the scm view
3. type to start the tree-search
4. notice that highlights are present

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[vince-fugnitto]

@colin-grant-work the changes now highlight the matches in the tree based on the search query. I'll need to confirm it still works correctly using the git built-in extensions.

I did notice the following issues that I'm not sure should be handled by the pull-request:

When no nodes are present, we still highlight the tree (which looks incorrect).

Changes is highlighted even though it is not part of the changeset but just a category (it is also highlighted in a different color):

[colin-grant-work]

@colin-grant-work the changes now highlight the matches in the tree based on the search query. I'll need to confirm it still works correctly using the git built-in extensions.

When no nodes are present, we still highlight the tree (which looks incorrect).

I'm happy to handle these in the current PR, though I'm not sure what behavior is most desirable. Arguably, if there are no changes, there's no need to render the top-level node at all (similar to how the Navigator doesn't render the top workspace node if it isn't a directory) so we could:

1. Not render a ChangeGroupNode if it has no children (make it invisible).
2. Not highlight the ChangeGroupNode even if it matches the search (either unconditionally or on the condition that is has no children)
3. Just remove whatever style code is making it a different color so that the highlight at least looks like the highlighting of other nodes.

I'm inclined to opt for 1 and 3. Don't render the node if it isn't informative, and if it is rendered, highlight the same as any other node. Does that sound reasonable?

[vince-fugnitto]

@colin-grant-work the changes now highlight the matches in the tree based on the search query. I'll need to confirm it still works correctly using the git built-in extensions.
When no nodes are present, we still highlight the tree (which looks incorrect).

I'm happy to handle these in the current PR, though I'm not sure what behavior is most desirable. Arguably, if there are no changes, there's no need to render the top-level node at all (similar to how the Navigator doesn't render the top workspace node if it isn't a directory) so we could:

1. Not render a ChangeGroupNode if it has no children (make it invisible).
2. Not highlight the ChangeGroupNode even if it matches the search (either unconditionally or on the condition that is has no children)
3. Just remove whatever style code is making it a different color so that the highlight at least looks like the highlighting of other nodes.

I'm inclined to opt for 1 and 3. Don't render the node if it isn't informative, and if it is rendered, highlight the same as any other node. Does that sound reasonable?

I know that it is done this way since it aligns with vscode, they display the changes top-level node despite no actual children (changes):

I think we should be consistent with the behavior present in vscode for the moment, and fix the highlighting of this node (removing the highlighting versus fixing the color).

[colin-grant-work]

@vince-fugnitto, I've pushed up a version that documents the breaking (and non-breaking) changes in the CHANGELOG.md and restricts highlights to non-group nodes.

[vince-fugnitto]

The changes work well for me, I now see that highlighting works well for scm.
I also verified the changes using the git built-in extensions instead of @theia/git:

"vscode-builtin-git": "https://open-vsx.org/api/vscode/git/1.39.1/file/vscode.git-1.39.1.vsix",
"vscode-builtin-git-ui": "https://open-vsx.org/api/vscode/git-ui/1.39.1/file/vscode.git-ui-1.39.1.vsix"