feat: add optional `additionalData` field to `KurtResult` (final stream event).

This is the first step to solving for parallel tool calls (see issue #33).

This commit adds a new optional field to KurtResult called additionalData which can hold an array of additional structured data entries, of the same type D that is used for the mandatory data field.

This solution has a few nice properties:

it is a non-breaking change, both for applications and for LLM-specific adapters
it extends the general case of any method that returns a structured data result (i.e. it applies to both generateStructuredData and generateWithOptionalTools without needing to create new methods that overlap partially with those)
it gives an "at least one" data entry (type system) guarantee, so that the application doesn't need to have paranoid code that worries about the case of zero entries.
it is easy for applications to opt out of dealing with: if they want to choose to only handle the first tool call, they can pay attention to only the data field and ignore the additionalData field. (note that if I had went the path of having multi-value methods separate from the current single-value methods, I would have needed to update the single-value methods to silently drop all additional tool calls, and that seems less ideal than explicitly giving all of the tool calls to the application, and letting it decide to drop or not drop)

You could argue that it would be "nicer" to have all the tool entries in one array, but I think the above benefits are reason enough to prefer this design.

Note that after this commit is merged, the next step is to update the adapters to start handling the multi-value case, making use of this new field. That work will actually be what is needed to fully resolve the #33 ticket.

FormulaMonks / kurt

feat: add optional `additionalData` field to `KurtResult` (final stream event). #34