I look forward to it, and I can use it together, so when can I use it?

There's a problem with this PR with null option values (0, "", etc.).
The llms.CallOptions struct doesn't allow to differentiate between when an option is set to 0 or not set (for numeric types int, float64...).
The official ollama client take options via the input type map[string]any, so when building the map (via makeOllamaOptionsFromOptions) I finally have a temperature, penalties etc. with a value of 0 even if the user didn't set the option.
The langchaingo "internal" clients seems to Marshal a struct with some omitempty markers at some point (which remove null values from the payload) or copy the null value.

For now I see two ways to fix this in refactoring the generic llms package:

1. either modifying llms.CallOptions fields as pointers (so nil value when not set), but this force to modify the other clients option management for non nil. But the fields are exported and this may break something
2. or like in chains: fix issue with overriding defaults in chainCallOption #632 in adding a boolean per field. Infortunately the boolean fields needs to be exported to be usable in the ollama package but this breaks nothing

To move forward and quickly propose a solution I go for 2. but I'm open to discuss and modify this as I'm not fully confident with this change.

@pdxrlj you can try this PR code if you want, feel free to give feedback on it