Introduce ChatMessageContent

[joseharriaga]

This is a draft of what the public API would look like.

Based on this prototype, my current assessment is that this change does not add a lot of value, and therefore, my current inclination is to not go ahead with it. Let me know what you think.

Summary:

We add a new class that looks like this:

public class ChatMessageContent {
    public IList<ChatMessageContentPart> Parts { get; }

    public ChatMessageContent(string text);
    public ChatMessageContent(IEnumerable<ChatMessageContentPart> parts);
    public ChatMessageContent(params ChatMessageContentPart[] parts);
}

We use it to replace:

1. ChatCompletion's IReadOnlyList<ChatMessageContentPart> Content property.
2. ChatMessage's IList<ChatMessageContentPart> Content property.

Q: How does this affect the code that customers write?
A: I believe it doesn't change much.

🟢 Example 1: Creating a ChatMessage
To create a ChatMessage, it is still more convenient to use the constructors that take a plain string or an IEnumerable<ChatMessageContentPart> than to have to instantiate a new ChatMessageContent using the same plain string or an IEnumerable<ChatMessageContentPart>.

🟢 Example 2: Reading the multimodal content of a ChatMessage
For example, to render the multimodal contents of a ChatMessage in some UI, users need to iterate through the Parts of the ChatMessageContent. In other words, the following:

foreach (ChatMessageContentPart part in message.Content) { ... }

Becomes:

foreach (ChatMessageContentPart part in message.Content.Parts) { ... }

While relatively trivial, this still looks like a minor regression in usability. We could mitigate it by making ChatMessageContent inherit from Collection<ChatMessageContentPart> instead of having a Parts property, but all this does is keep the experience the same (not any worse, not any better).