"Fix problems" as a command in the agent API

[odisseus]

Partially implements https://github.com/sourcegraph/jetbrains/issues/117.

Test plan

1. Check out this PR: https://github.com/sourcegraph/jetbrains/pull/1859
2. Run this command:

   CODY_DIR=/path/to/cody ./gradlew runIde -PforceCodyBuild=true

3. Open any source file in any project
4. Select a range of lines and right-click. The new action will be available in the Cody sub-menu.

[dominiccooney]

Here's some pointers to get started:

• VSCode API reference specifically registerCodeActionsProvider, CodeActionsProvider, QuickFix : CodeActionKind, CodeActionContext especially diagnostics, etc.
• vscode/src/code-actions/fixup.ts FixupCodeAction, this is registered in vscode/src/main.ts registerChat when we new CodeActionProvider() (I know...)
• Subsequently, VSCode invokes the provider with diagnostics around the cursor when the user presses Cmd-. etc.

You need to do a design to reuse the logic in FIxupCodeAction.

Your main choice is at what level to make that reuse happen. Trace back through Agent and vscode-shim.ts to see how much of VSCode code actions API is wired up, how much of diagnostics are wired up, etc.

If the wiring is in place, do whatever last bit of plumbing to connect it end-to-end with invoking a JetBrains action and triggering a JetBrains edit.

If the wiring is not in place, you have basically two choices:

1. Add an agent ClientCapability like "I support code action providers" and extend Agent, vscode-shim, Kotlin side to support VSCode code action provider API and pass diagnostics.
2. Design a higher level API around fixups, refactor the TypeScript implementation to provide that API then connect VSCode code action providers in to that API, and make a similar path through Agent for invoking the same higher level API.

Either of these choices can work and have different tradeoffs. The first approach can be high leverage and not disturb the TypeScript implementation used by VSCode... if the VSCode shim API fidelity is good, it will "just work."

The second approach is more design work but the results are better because you can fit your API abstraction level to the task at hand.

For example, Edits basically uses the second approach (there's high-level Agent protocol like editTask/accept etc. and it calls a FixupControlApplicator object) but it is not a completely black and white choice (at one level of abstraction down, the FixupControlApplicator causes text edits and of course they use the VSCode API --> shims --> Agent --> Kotlin route.)

Hope this helps.

[RXminuS]

1. Add an agent ClientCapability like "I support code action providers" and extend Agent, vscode-shim, Kotlin side to support VSCode code action provider API and pass diagnostics.

I agree and think that adding general CodeActionProvider support to the agent has my preference here. I'm available to pair on this @odisseus if that's helpful?

[odisseus]

I'm not so convinced about the general support for CodeActionProvider. I see that the CodeAction can contain not just a source edit, but also an arbitrary VS Code command. In IntelliJ, we may or may not have equivalent commands. Is this field actually used anywhere in Cody?