chains: expose GetLLMCallOptions

[lucaronca]

Motivation

This method is very useful for a user who wants to use an LLM GenerateContentmethod when working with parameters defined in a chain, I see no advantage in keeping it private.

PR Checklist

• [x] Read the Contributing documentation.
• [x] Read the Code of conduct documentation.
• [x] Name your Pull Request title clearly, concisely, and prefixed with the name of the primarily affected package you changed according to Good commit messages (such as memory: add interfaces for X, Y or util: add whizzbang helpers).
• [x] Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• [x] Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. Fixes #123).
• [ ] Describes the source of new concepts.
• [ ] References existing implementations as appropriate.
• [ ] Contains test coverage for new functions.
• [ ] Passes all golangci-lint checks.

[tmc]

Not opposed in principle but do agree with gemini regarding documenting exported symbols.

I've been working on some refreshes and improvements and this is in consideration -- I agree there's little reason to hide it but want to think it over some more..

[lucaronca]

Not opposed in principle but do agree with gemini regarding documenting exported symbols.

I've been working on some refreshes and improvements and this is in consideration -- I agree there's little reason to hide it but want to think it over some more..

@tmc sure, keep in mind that when creating a custom chain and defining the Call method, I receive a list of options ...chains.ChainCallOption. Therefore, when I later call the GenerateContent method of an llms.Model, it's very convenient to have a method that maps these options to []llms.CallOption. Alternatively, I should rewrite as a user a function that does exactly the same thing :/

Anyway, I added documentation to the exported method as suggested.