feat(search): search 2.0

[brandonspark]

What:

This PR revamps Semgrep's IDE search to have a more accessible UI, as well as being more responsive and more expressive in some ways.

Why:

Semgrep's search is currently nice, but I wouldn't use it because of several UX troubles. Currently, you have to go through a bunch of buttons clicks, and search is pretty slow to boot.

How:

We deprecated the VS Code API based UI for one which is entirely in React, in the form of a webview. This lets us have full customizability over what the UI looks like.

We also made several engine improvements which are consumed by the new UI to offer better UX, such as:

• the ability to write multiple patterns (including negated patterns) to refine search
• semantic fixes
• streaming searches
• includes/excludes based on paths

Test plan:

Thorough manual testing.

PR checklist:

• [X] Purpose of the code is evident to future readers
• [ ] Tests included or PR comment includes a reproducible test plan
• [X] Documentation is up-to-date
• [ ] A changelog entry was for any user-facing change
• [ ] Change has no security implications (otherwise, ping security team)

If you're unsure about any of this, please see:

• Contribution guidelines!
• One of the more specific guides located here

[brandonspark]

(tagging @bkettle if you have any concerns)

[brandonspark]

@ajbt200128 let me know how you feel about the current state management. i tried to pull all the state to the top of the App via a new useStore which simply gives the entire store object, which is then modified via a useSetStore hook which causes rerendering of the tree

i know you had reservations and wanted to use useState, but i wanted to avoid the scenario where i have to pass down an entire setState function through the whole tree. with the useSetStore hook, any part of the tree can trigger a re-setting of the store, without needing to pass down the setter everywhere