`contents_record()` and `contents_replay()` could operate on list of turns

[gadenbuie]

chat$get_turns() |> ellmer::contents_record()
Run `rlang::last_trace()` to see where the error occurred.
Error in `ellmer::contents_record()`:
! Cannot record or replay a list.
ℹ Only `ellmer::Content` or `ellmer::Turn` classes or subclasses are currently supported.

But it'd be very convenient to be able to round trip

first <- chat$get_turns() |> contents_record()
chat2$set_turns(contents_replay(first))

[gadenbuie]

Here's a basic example of most of what I want to do in general

history <- list(
  system_prompt = chat$get_system_prompt(),
  turns = chat$get_turns() |> lapply(ellmer::contents_record)
)

saveRDS("chat-history.rds")

# new session ----
chat <- chat_openai() # maybe even a different provider
chat$set_tools(tools) # maybe needed?

history <- readRDS("chat-history.rds")
chat$set_system_prompt(history$system_prompt)
chat$set_turns(lapply(history$turns, contents_replay))

Having contents_record() and contents_replay() operate on lists of turns wouldn't reduce much of this code, really, so I'm not sure how useful this all would be. Maybe this is something to consider when reviewing internal class abstractions in the future -- possibly a Turns() class?

[gadenbuie]

For historical record, I talked through some of this with @schloerke. We'd love to have a Chat method for contents_record() and contents_replay(), i.e. an easier way to serialize and restore an entire chat, but there are more than a few edge cases that need to be though through. Currently, the most type-safe way to roundtrip data through contents_record() and contents_replay() is at the Turn() and Content() level. If we introduced a Turns() class, that might move the boundary up to chat$get_turns().

Anyway, this issue will need more thought and design before implementation, even though it looks superficially easy.

[hopessugar]

Thanks for the detailed explanation, @gadenbuie! That makes complete sense regarding the need for type safety and an intermediate Turns class rather than just handling raw lists. I appreciate you clarifying the architectural vision.

I'll close this PR for now to keep the board clean. I would be happy to take a crack at implementing that Turns class if you have a specific design in mind, otherwise I will keep an eye out for other issues to contribute to while I draft my GSoC proposal. Thanks!