Refactor CodeChange code about mentat

[PCSwingle]

@jakethekoenig completely agree! Last week while I was making these changes I realized that concrete change wasn't really needed, and mapped out a completely different architecture that I really like with @biobootloader. I'll keep this issue as-is, but in #94 I lay out the new structure we agreed upon; it pretty much turns the AbstractChange into FileEdit (although FileChange would be a good name too) and removes the ConcreteChange completely.

[waydegg]

Can we close this issue?

[jakethekoenig]

I really like the idea of decoupling the LLM specified file change format and our internal file change object. I wonder if instead of calling them ConcreteChange and AbstractChange we might want to call them something like LlmResponseFormat (or LlmChangeParser?) and FileChange. As I understand it the responsibilities/differences of the two objects are:

ConcreteChange or LlmResponseFormat

• Provide a prompt which describes the format to specify a change in. Like is currently done here.
• Provide a function which parses responses which have been received from an Llm prompted with the LlmResponseFormat's prompt block and returns a collection of FileChange objects.
• We may make many of these and experiment with different prompts for different Llms and evaluate things like how consistently Llms can respond in the correct format, how many tokens they use both in prompt and response and if they affect response quality.
  (Maybe you imagine the ConcreteChange isn't the LlmResponseFormat which is a third thing but is the actual response describing a file change received from the Llm?)

AbstractChange or FileChange

• Represents a change to a file precisely with all the information you'd need to make the change e.g. path, line #, text to insert.
• Has a function to pretty print it for a user to accept/reject.
• Has a function which actually makes the edit.
• Once we settle on a design for this object it's unlikely to change much compared to LlmResponseFormat where there's a lot of experimentation to do.

Let me know it my summary and understanding aren't quite right but I think the dichotomy is more like Raw/Parsed than Concrete/Abstract.

[PCSwingle]

Slight change to the plan for AbstractChange after thinking and working on it for a bit: Planning on having Additions, Deletions, and Rename subchanges -- the Rename change will have a new name where None will represent a deletion, and a Rename when the file does not exist will represent a creation