feat(autoedit): refactor renderer code to simplify iteration on decor…

[hitesh-1997]

The PR refactors the current autoedits renderer to use a common schema for which Decorations can use.
Idea is to make it easy for anyone to try to implement a new decoration type without knowing the details on diff computation.
The common schema is in the file here

Test plan

Testing examples in cody-chat-eval and playing with the rendere to make sure we don't have any regression

[beyang]

Please add documentation describing what the interface contract is. Interfaces generally should be documented thoroughly to indicate behavior/constraints/invariants that implementors and callers should satisfy.

I see two places where this interface is used, (1) one in the main auto-edits command and (2) the other in the test command. In (1), clearDecorations and dispose are called together. In (2), it doesn't appear that dispose is ever called. So some clarity around how concrete implementations should be used would clarifying here. Should instances be kept around and used for multiple rounds of displaying decorations, or should new instances be created whenever new decorations are shown.

[hitesh-1997]

Nice Insight !!
clearDecorations and dispose were coupled and dispose should anyways clear the decorations.
Added in the documentation that each decorator instance should be used only for one decoration and disposed after the decoration is used, and we should clear the decoration on dispose.

Does the updated implementation look okay ?

[beyang]

Here, we're passing an enum-switch around, which means that multiple places in code (here and then in AutoEditsRendererManager) have to be aware of this enum, which makes the code more brittle, hard to update, and hard to test. If more cases are added in the future, we need to remember to add the appropriate switch cases and handling in tests.

It would be cleaner to pass a function here that creates the Decorator instance we want the AutoEditsRendererManager instance to use. So something like this:

new AutoEditsRendererManager(
   (editor: vscode.TextEditor) => new DefaultDecorator(editor)
)

And then in manager.ts:

export class AutoEditsRendererManager implements vscode.Disposable {

    constructor(private createDecorator: (editor: vscode.TextEditor) => AutoeditsDecorator) { ... }

    public async showEdit(options: AutoEditsManagerOptions): Promise<void> {
        ...
        this.activeEdit = {
            uri: options.document.uri.toString(),
            range: options.range,
            prediction: options.prediction,
            decorator: this.createDecorator(editor),
        }
        ...
    }

[hitesh-1997]

That's a good insight. Modified the changes as per suggestion !!

[beyang]

Please address the one remaining change, otherwise LGTM!

[valerybugakov]

I'll merge this one to merge my follow-up PR into the main branch. It will be less risky because my PR refactors more logic for which we don't have test coverage yet.