Add "Switch to using C/C++ Editor (LSP)" to quick fix of Codan/parser

[jonahgraham]

When codan or parser finds an error one of the quick-fixes should be to switch the project or workspace to using the C/C++ Editor (LSP) so that users can discover that the CDT LSP implementation resolves their problem.

PR incoming for this.

[ghentschke]

How would a possible use case look like?
A user opens a C/C++ source file in the old C/C++ editor. Codan/parser finds an error and creates a marker. One quick-fix would be to switch on the Set C/C++ (LSP) Editor as default flag only. But this would imply that all files for the given project/workspace opened in the old editor has to be closed and re-opened in the LSP based editor? Then clangd (maybe) offers a quick-fix for the problem?

Or is the use case that the "LSP quick-fix" should be displayed only when there are no other quick-fixes available?

[jonahgraham]

The idea is that we have lots of markers being created because of parse errors in "old" cdt. I want to provide visibility to those users that lsp is available. And yes, the quick fix (which will start a short wizard) will reopen editors.

Does that sound reasonable to you?

[ghentschke]

Does that sound reasonable to you?

yepp, but I would suggest that vendors can disable this quick-fix. This would be necessary when the new editor should be used by customers only for certain C/C++ project types (e.g. not for old managed build projects without compile_commands.json file available).
Maybe we can introduce a check via extension point which asks if a given project supports the new editor.