refactor: tree search box into React widget and enhance UX and styling

[ndoschek]

What it does

Resolves GH-16657

• Refactor SearchBox to a ReactWidget for improved state handling
• Update icons in the search box to use Codicons
• Update and simplify CSS rules

How to test

• Test the tree search box in different tree views, e.g. in explorer, outline, scm view
• Verify the behaviour described in the issue is fixed

Follow-ups

Breaking changes

• This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines
• User-facing text is internationalized using the nls service (for details, please see the Internationalization/Localization section in the Coding Guidelines)

Reminder for reviewers

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

[lucas-koehler]

Thanks for the fix @ndoschek . The changes look pretty good to me and the search box still worked as expected using it in the explorer and scm views. I could not detect any overflow :)

Just one question. Why were the constants for the style classes (i.e. SearchBox.Styles) removed? The old approach seemed quite nice to me considering some of the classes are used multiple times.

[ndoschek]

Thanks for the review @lucas-koehler!
There wasn't a strong technical reason for removing the constants. I mainly found it a bit easier to read with everything in one React component now, especially when conditional classes are involved. For example:

className={`${SearchBox.Styles.SEARCH_BUTTON} ${SearchBox.Styles.ACTION_LABEL} ${this.isFiltering ? SearchBox.Styles.LIST_FILTER_ICON : SearchBox.Styles.LIST_SELECTION_ICON}`}

instead of

className={`theia-search-button action-label ${this.isFiltering ? codicon('list-filter') : codicon('list-selection')}`}

That said, I agree the constants can be beneficial however. I'm happy to revert this or adjust the approach if you insist or have a better idea for this.

[lucas-koehler]

@ndoschek Thanks for the explanation. No, I do not insist on reverting this. Both approaches are fine for me with different (dis)advantantages. We can merge it like this