Address inconsistency between `LLMInterface` and actual LLM client implementations

[rweald]

The LLMInterface defines generate_response -> Tuple[str, Dict[str, Any]]:, but none of the llm clients actually return that type, they all attempt to just return a standalone str.

I also noticed that the callers of generate_response typically expect it to be a single string value as well.

As of this filing, this inconsistency is the reason for all the remaining type errors in the codebase. There is also a risk a sneaky runtime bugs if someone builds off the LLMInterface defined return type, but then gets surprise null values for the second part of the tuple.

[rweald]

From my reading of the code there seems to be 2 options to address:

1. Update the LLMInterface definition so it's return type is just str.
2. Update all the llm client classes that implement the interface, and then also update all the callers to handle the new response tuple.

While 2 may be optimal in the long term, I wonder if just starting with option 1 to reduce the risk of runtime bugs, and restore type safety with a minimal blast radius might make the most sense.

[rweald]

@sator-labs with some of the large PRs merged, thoughts on addressing this one. I'm looking at adding a new client and would like to know which direction that new client should take lol. True support for the LLM interface, or matching what existing clients is outputting.