feat: introduce chain awareness in chain processors to nest them

[chr-hertel]

Changes:

• Processors can be ChainAware now and with that leverage other processors recursively.
• SturcturedOutput\ChainProcessor now also supports plain response_format and decodes it to an assoc array, see example and screenshot below
• Multiple OutputProcessor can interfere now on the same response => no weird return, but via Output instance

[OskarStark]

From what I can see, this PR looks promising, but I am not that deep into the chain thing 😄 Maybe add some more unit tests before merging? I can support you if you want

[chr-hertel]

I'm so lazy about adding tests because I'm still unsure about the OOP slicing - this is why i currently mostly rely on the "functional" tests a.k.a. examples

[chr-hertel]

still flip flopping between events and processors - what do you prefer?

those processors are explicit but the event dispatcher is super common in symfony as extension point

[OskarStark]

Looking at this PR, I feel the chain thing is quite "complex" or "complicated". My feeling is that events will bring up the same results, while the code is less cluttered.

[OskarStark]

Double checked the events PR and now I am not sure anymore if events will really result in better code 🤔 What is your feeling?

[chr-hertel]

since i'm moving away from return values and using those input/output objects and calling all instances of processors the only difference from mechanical point of view is the missing EventDispatcher in between.

this is more like the Serializer component with encoder, normalizers, etc - so explicit extension points.

only if we end up having more events across the layers (chain, model, platform) later and implementations on top of the extension points will leverage more than those two here, there is a benefit in events due to the ease of use for implementation - plus symfony devs being familiar with events and better debugging

[chr-hertel]

this is why i would delay the decision for events and go with this implementation first - but wanted to double check your poc implementation again

[chr-hertel]

but yes, similar to that serializer/normalizer thing it get's confusing/complex by stacking those capabilities

[chr-hertel]

so, i think with an custom output processor you could with a additional logic like response instanceof ToolCallReponse or similar inject the additional message that your poc has.

this was one example of mine with a stupid processor just always adding on in and out:

[OskarStark]

Should be part of the docs in the README

[OskarStark]

Should be part of the docs in the README

[chr-hertel]

Should be part of the docs in the README

:100: the "docs" are s**t right now

[OskarStark]

We are under heavy development, so its fine to have shitty docs 😄