refactor(message): update message api types

[0xMochan]

completion::Message refactor

This PR performs a very large refactor for how messages are handled. There are 2 parts that are combined to allow for full API access to all providers.

Message struct

This PR defines a general Message definition that serves to be the singular data point for message histories alongside the interface for prompting moving forward. This interface encapsulates all of the different input and responses you might get when conversing with any provider, including multi-modal inputs (images, etc), tool calls and results, and assistant powered replies. It covers a vast majority of provider specific and general features.

From and TryFrom implementations

Each provider now has it's own set of Message structs representing a closer model of the provider specific API. The provider is responsible for implementing a From and/or TryFrom to convert between the generic message <-> provider specific message converting the data between the formats.

Prompts are supplied as Into<Message> and message history are Message. Providers then convert this into a single stream of their own Message to then pass to the provider's API calls. When a response is given, the reverse is made.

Future

In the future, there will be more implementations of Into<Message> and other abstractions that'll build upon this pattern. This includes further abstractions to make working with images, documents, and audio with specific provider apis more seamless, making tool calling loops easier (prompt -> assistant -> tool call -> tool result -> assistant -> response), and easier management of chat histories.

Caveats

This PR has gotten too large, but to avoid it growing even further, some concessions were made. These should result in their own issues for further discussion:

• I found that EternalAI currently is able to accidentally have 2 system messages which would cause an issue with the provider.
• Gemini function arguments are oddly configured and likely needs a second look at
• completion::completion2 is poorly named (can be resolved in the current PR).
• message::UserContent(Text), message::AssistantContent(Text), and message::ToolResultContent(Text) take in message::Text but could directly take in a String for simplicity
• ToolResult is placed under UserContent instead of another top-level enum variant.

[cvauclair]

Amazing work, that was a big one!

Couple comments while I wait for the final commits

[carlos-verdes]

I find the PR super big, we can try to create smaller PRs to cover these changes progressively.

I left some comments

[cvauclair]

Excellent work @0xMochan !

Found a couple bugs but overall this looks 🔥

[carlos-verdes]

I really need this PR in order to finish the tool calls issue (send the tool response back to the model to get human readable answers).
Is there anything I can do to help closing this PR faster?

[0xMochan]

I really need this PR in order to finish the tool calls issue (send the tool response back to the model to get human readable answers). Is there anything I can do to help closing this PR faster?

This is planned to merge in 24 hours!

[cvauclair]

Couple of docs changes but after that let's send it! Amazing work! 🔥

[0xMochan]

LGTM!!!!

[cvauclair]

Send it! 🚀

[carlos-verdes]

This PR breaks DeepSeek provider, the problems is how DeepSeek provider builds the client, I'll fix this on my next PR