Use OpenAI Python Lib instead of using aiohttp for OpenAI compatible API

[evschlenz]

To properly support streaming tool calls (ggml-org/llama.cpp#12379) and to improve overall code cleanliness, I propose migrating to the official OpenAI Python library (https://pypi.org/project/openai/) instead of using aiohttp directly for OpenAI-compatible endpoints.

I tested my changes with llamacpp b7549, functiongemma (original and my custom finetune) and the LlamaCppServerClient:

llamacpp/llama-b7549/llama-server --host 0.0.0.0 -c 32000 -m llama_models/functiongemma-270m-it-q8_0.gguf --port 8090

as well as vllm v0.13.0, Qwen3 30bA3b and the LlamaCppServerClient:

podman run --device nvidia.com/gpu=all \
        -v ~/.cache/huggingface:/root/.cache/huggingface \
        -v ~/ai/vllm/models:/root/models \
        -p 8000:8000 \
        --ipc=host \
        docker.io/vllm/vllm-openai:v0.13.0    \
        --download-dir /root/models/ \
        --model /root/models/Qwen3-30B-A3B-Instruct-2507-AWQ-4bit/ \
        --enable-auto-tool-choice \
        --tool-call-parser hermes \
        --gpu-memory-utilization 0.95 \
        --max-num-seqs 128 \
        --dtype auto \
        --swap-space 16 \
        --trust-remote-code \
        --host 0.0.0.0 \
        --port 8000

both with their native tool calling.
Since I do not have an OpenAI account, I cannot validate the functionality against their api.
This pull request should fix compatibility with functiongemma (on lamacpp at least) as well.

A potential follow-up would be to migrate GenericOpenAIResponsesAPIClient to the OpenAI library as well. However, since I am not really familiar with the Responses API, I left it as is for now.

[acon96]

Thank you for this. Yes I think it makes sense to continue migrating to the "official" python libraries to ensure proper compatibility after doing the Ollama one. Once this is published I will take a look at it for sure.