VS Code Extension should be updated to reflect the Kiota.Config and plugins / manifest work

[sebastienlevert]

Tasks

Beta Give feedback

1. Restructure VS Code to support Kiota workspace
2. Support adding a new client (from path, URL or search)
3. Support adding a new plugin(from path, URL or seact result
4. Enable API Explorer to work in the context of a selected client or plugin
5. Add search for an API
6. Refresh for the API Explorer + Selected Paths
7. Welcome Screen
8. Add "Browse" and the "Default" options when selecting an output directory #4719
   enhancement vscode-extension +2
   
9. Display the name of the client / plugin being edited on API Explorer #4720
   enhancement vscode-extension +2
   
10. Enable regeneration after a user generates a client or plugin and without closing the description #4721
    enhancement vscode-extension +2
    
11. Collapse/Hide workspace area if no workspace.json file exists #4828
    enhancement type:enhancement type:feature vscode-extension +4
    
12. When a deeplink has a specific endpoint, the description file should load with the endpoint 'pre-selected'
13. The VSCode extension README should be more explicit and complete #3069
    needs more information vscode-extension +2
    
14. When starting a new folder, Kiota should not show the "Kiota directory not found" error #4855
    type:bug vscode-extension +2
    
15. Entering openapi path with quotes breaks entry #4765
    type:feature vscode-extension +2
16. Detect open folder in VS Code is TTK project and change output path for Copilot Plugin #4766
    type:feature vscode-extension +2
    
17. Add migration action to the contextual menu for locks in extension #4548
    type:bug vscode-extension +2
    

[baywet]

@sebastienlevert to provide wireframes and specs

[sebastienlevert]

Link to the mockups: https://microsoft-my.sharepoint-df.com/:p:/p/slevert/EYKWnSnCqfNHlSYZYPAmwzoB2BkKSCXpbX4lyVk4aVmQNw?e=nm6hc4

[baywet]

One important decision to make for the extension: do we want to enable both the kiota lock and the config experiences (behind a feature flag) like we do for the CLI? or do we want the extension to be edge and only support the config aspects? @sebastienlevert
This in turns will drive the integration with the JSON RPC server and other implementation details.

[sebastienlevert]

This is a good question... Would this be possible to drive conditionally the work in both lock mode and in workspace mode? Let's say we had a config in the extension that says "enable preview features", then the "complex" tree and capabilities would show up. If not, then it's business as usual... If this is something that is possible, I'm happy to lean on this to be able to offer it sooner to developers.

[baywet]

You'll see during the status meeting, but supporting multiple experiences will add to the overall workload, and we're already falling behind on a bunch of things. I'd vote for having the extension be edgy only, especially since the adoption is not that broad today anyway.