Add support for reasoning field from gpt-oss models while maintaining backward compatibility

[LubyRuffy]

Hello go-openai maintainers,

First and foremost, thank you for your excellent work on this essential library for the Go community.

I am writing to report a compatibility issue when using the library with gpt-oss models, particularly those served through popular platforms like Ollama and LM Studio.

Problem Description

The library's ChatCompletionStreamChoiceDelta struct is designed to parse reasoning steps from a stream using the JSON tag reasoning_content.

While this works for certain models, the emerging standard for gpt-oss models, as seen in community implementations, is to use the field name reasoning. This discrepancy prevents the library from correctly unmarshaling the reasoning data from these models, leaving the ReasoningContent field empty.

Evidence

1. Current Library Implementation (chat_stream.go):
The struct expects the reasoning_content field.

type ChatCompletionStreamChoiceDelta struct {
    // ... other fields
	ReasoningContent string `json:"reasoning_content,omitempty"`
}

2. Actual gpt-oss JSON Output (Example from Ollama):
The model stream provides a reasoning field instead.

"delta": {
    "role": "assistant",
    "content": "",
    "reasoning": "This is a reasoning step."
}

(Full JSON chunk examples from both Ollama and LM Studio can be provided if needed.)

Importance of Backward Compatibility

A key consideration is that simply renaming the JSON tag from reasoning_content to reasoning would likely be a breaking change for users who rely on the current implementation for other models (e.g., DeepSeek). Any potential solution should ideally preserve this existing functionality.

Request

To improve compatibility with the growing gpt-oss ecosystem, would it be possible to enhance the library to support the reasoning field in addition to the existing reasoning_content?

We believe that accommodating both formats would make the library more robust and versatile for all users. We defer to your expertise on the best architectural approach to implement this.

Thank you for your time and for considering this request. I am happy to provide any further information or assist with testing.