Standardize several additional forms of content

[stephentoub]

It's possible for implementations to create their own custom AIContent-derived types, and that's valuable when there's something the service consumes or produces that's non-standard. However, there are a variety of kinds of content that are becoming more standard and that could be abstracted over if the right types were in the core abstractions library:

• Tool execution results. When a code interpreter tool is used, or a web search tool, etc., some services send back a piece of content containing the result. We might want a Code Result Content, or a ServerToolResultContent. Or maybe we add a ToolResultContent that's a base for FunctionResultContent.
• Citation / reference content. Investigate adding new AIContent-derived type for citations/references #5527
  -....

We need to do a pass through all of the currently available services and determine what is common enough (and/or simple enough with little need for future variation) now to warrant standardization.

cc: @luisquintanilla, @SteveSandersonMS

[jeffhandley]

@rogerbarreto Please take a look and report during Wednesday's sync on if we need this ahead of GA. Assigned to you for triage.

[rogerbarreto]

I would also like to add that similar to CodeContent we can have HTMLContent, Markdown, Mermaid and so on, which are pretty much accepted standards out there.

We might be able to represent this as TextContent if we tagged TextContent with a mime type

I think that would make sense if the plan is a TextContent to be a specialization of DataContent or move the MediaType up in the stack to the AiContent.

If not we can have Format or other name that align with text subtypes.

I would add the ErrorContent as part of this task, as I brought it up in the ISpeechToText impl.

[stephentoub]

I would also like to add that similar to CodeContent we can have HTMLContent, Markdown, Mermaid and so on, which are pretty much accepted standards out there.

Couldn't DataContent just be used, with a mime type indicating which it is?

We might be able to represent this as TextContent if we tagged TextContent with a mime type

I think that would make sense if the plan is a TextContent to be a specialization of DataContent or move the MediaType up in the stack to the AiContent.

We seem to be landing in place where TextContent is a special-case for the super, super common case of human-readable text (having a mime type would muddy the waters), and all other content is DataContent.