Make BeanOutputConverter more extensible

[markpollack]

Summary

• Makes BeanOutputConverter class more subclass-friendly by changing access modifiers for key fields and methods
• Extracts template string in getFormat() to allow customization by subclasses
• Provides better extension points for customizing behavior

Fixes #1985

[ThomasVitale]

@markpollack since BeanOutputConverter implements StructuredOutputConverter, would it be enough to create a custom StructuredOutputConverter implementation if a different logic is desired?

I can already define a MyBeanOutputConverter which implements StructuredOutputConverter and define my custom logic for the schema generation. Actually, that's what I do in my projects. I implemented my own version, and re-used the JsonSchemaGenerator class for generating the schema, which is the same logic used for tool calling. I didn't experience limitations in terms of extensibility.

I'm afraid that by opening up methods and fields in BeanOutputConverter, it will be more difficult to evolve the structured output support due to backward compatibility. We had a similar issue in the old FunctionCallback implementations, which exposed methods to customise schemas and ObjectMapper, and that made it difficult to change the internal implementation since all the internal methods were protected, leaking internal implementation details and preventing from changing the implementation. In that case, we solved it by introducing a different API (ToolCallback), but here it would be more challenging.

I would tend to suggest evolving BeanOutputConverter to be a final class. Customizations would still be possible either via a delegate pattern or by introducing a custom implementation.

What do you think?