Add model prop to useChat hook to remove the need for a backend

[The-Best-Codes]

Add model prop to useChat hook to remove the need for a backend

This PR introduces the model prop to the useChat hook, enabling direct interaction with Language Model V1 compliant AI providers (e.g., Google, Groq, and other models from @ai-sdk) directly from the client-side, thus removing the need for a dedicated backend in simple use cases.

Addresses: #5140

Changes:

• Added model prop to UseChatOptions: The UseChatOptions interface now accepts an optional model property of type LanguageModelV1.
• Conditional API Call: The triggerRequest function now checks if a model is provided. If so, it uses the model's doStream method to interact with the AI provider. Otherwise, it defaults to the existing callChatApi function, which requires a backend endpoint.
• Streaming Implementation: When a model is provided, the PR implements a streaming mechanism using TransformStream and WritableStream to handle the response from the AI provider. The response is processed chunk by chunk, updating the chat messages in real-time.
• Updated chatKey: The chatKey used for SWR is updated to include the model instance if it is provided, ensuring unique cache keys for different model configurations.
• Typescript improvements: Added the language model types to the existing types.

Usage Example:

"use client";
import { createGoogleGenerativeAI } from "@ai-sdk/google";
import { useChat } from "@ai-sdk/react";

// Existing function, I made no changes here
const google = createGoogleGenerativeAI({
  apiKey: "(pass the key from somewhere)",
});

function ChatComponent() {
  const { messages, append, input, setInput, handleSubmit } = useChat({
    model: google("gemini-2.0-flash-001"), // Pass the model instance - this is the change I made. You can still remove this prop and use the API by default. This removes the need for a backend, not the option.
  });

  return (
    <div>
      {/* Some UI */}
    </div>
  );
}

export default ChatComponent;

Super open to changing this if it's not what you had in mind. 😀

[The-Best-Codes]

Please do not merge this PR yet. I need to do some more tests. 🫤

[The-Best-Codes]

I'm done testing, ready for feedback 👂

[qieman]

Hope the code can be merged quickly, as I want to use the API key directly in the client instead of relying on server forwarding.

[The-Best-Codes]

@qieman So far nobody has looked at this, it seems. It's been over a week 🥲

[rob-benzo]

Vercel when will this merge 👀

[lgrammel]

@The-Best-Codes I'm envisioning a transport abstraction where you can plug in transports other than http, and a potential transport* could be in-browser execution (with direct model invocation as a special case that is close to what you show here). The main difference would be how it's configured such that the transport polymorphism works well.

Feel free to leave this PR open - I might include parts of it when I get around to add a special direct model invocation "transport".

• the name "transport" will most likely change since it's not the best for e.g. in-browser execution

[The-Best-Codes]

So @lgrammel should I close this PR?

[lgrammel]

@The-Best-Codes you can just leave it as is for now - I will come back to it in time.

[The-Best-Codes]

Merge conflicts. Apparently that rebase didn't go quite right... 😳