Add non-breaking TemperatureOpt field to ChatCompletionRequest that can be set to explicit zero.

[misberner]

This PR adds a TemperatureOpt *float32 field to ChatCompletionRequest, that allows distinguishing between an unset (default) temperature and explicit zero. This has been reported in several issues (e.g., https://github.com/sashabaranov/go-openai/issues/9), but this solution explicitly proposes a non-breaking change.

OpenAI doc: https://platform.openai.com/docs/api-reference/chat/create#chat-create-temperature

The new field is taken into account via custom JSON marshaling/unmarshaling functions, resorting to the legacy Temperature field (now marked as deprecated) whenever TemperatureOpt is not set. The unmarshaling logic prioritizes the legacy Temperature field whenever unambiguous to avoid incompatibilities; TemperatureOpt is only used when necessary to represent an explicit zero. A newly added GetTemperature() method allows programmatic users to get the temperature value that would be used for marshaling.

Note: There is one breaking change, which I think however can be regarded as sufficiently minor to justify ignoring it: when unmarshaling a ChatCompletionRequest with an explicit temperature setting of zero, then setting the legacy Temperature field to zero, and then re-using/re-marshaling the request, the result will be a request with an explicit zero temperature, rather than (as would previously be the case) a default temperature setting. But this seems pretty fabricated to me.

Testing is done via unit test, ensuring correct marshaling and unmarshaling behavior in various scenarious (no field set - default temperature, legacy field set, new field set, both field sets, explicit zero temperature).

Issues:

• https://github.com/sashabaranov/go-openai/issues/9
• https://github.com/sashabaranov/go-openai/issues/678