WIP: Introduce a new ell.interactive API and example.

[kwlzn]

This introduces ell.interactive(), a new experimental API helper for bi-directional interaction with an LMP which can be used for various interactive scenarios w/ append-mode contextual history. It uses python's context manager paradigm to provide a session-like object that accumulates all message types (system, user, assistant and tool call/results w/ eager mode execution) - where the user only has to worry about examining the last response and sending the next one rather than managing that themselves.

The basic idea is that instead of defining a minimal @ell.complex method and calling it repeatedly with an externally managed messages list like in the multi-step tool example to achieve dynamicism, you can just do something like:

with ell.interactive(...@ell.complex params here...) as session:
    session.set_system_prompt(system_prompt)
    ...
    response = session.send(prompt)
    while not some_multiturn_condition_is_met(response, ...):
        ...
        next_prompt = read_and_react_to(response, ...)
        response = session.send(next_prompt)
        ...

I haven't thought too much about tracking/versioning nor have I tested it inside ell studio yet, but wanted to float the idea eagerly via a WIP PR for feedback/thoughts/guidance on how best to proceed in alignment with the projects goals.

Feedback welcome!

btw, I run the demo with uv like so:

om:ell kw$ export ANTHROPIC_API_KEY="..."
om:ell kw$ uv --no-cache run --with .[anthropic] --no-project ./examples/interactive_tool_diff.py
...

[MadcowD]

I love this have you seen: https://github.com/MadcowD/ell/blob/main/docs/ramblings/0.1.0/chat.md

[kwlzn]

I love this have you seen: https://github.com/MadcowD/ell/blob/main/docs/ramblings/0.1.0/chat.md

no, but thanks for the pointer! this definitely helps illuminate the versioning story and top level API alignment stuff.

some changes I'll make based on this:

1. I'll add type checking to send() to handle lists (for pre-filling) and the ell message type helpers (system, user, assistant etc) - with bare strings defaulting to ell.user() wrapping.
2. I'll drop set_system_prompt() in favor of send(ell.system(...)) to simplify and be more idiomatic.
3. I'll explore ell.function or a context-block code extraction versioning strategy. at first glance, the context-block approach feels a little more compact/portable for this case, but ell.function appears to have broader utility beyond this. I'll experiment and see what works well (and maybe raise a discussion on #ell-future) - but let me know if you feel strongly either way.
4. I'll expose public (readonly?) access to the stored msg history. I'll probably avoid implementing the "history override" param to send() for now to keep things dead simple (and users can always implement their own message history handling loop for more complex cases). hist override can always be added later as/if a clear demand for it materializes.