feat: support parallel calls

[andreitava-uip]

Rough implementation draft to support parallel subgraphs. Successfully ran two IS tools with pre-execution guardrails in parallel.

Not yet done:

• fix all guardrail actions to correctly extract the tool call. Only done filter to be able to test, also need to do escalate
• fix message updating. This is an existing bug in all our code. If you update message.tool_calls, that does not actually change what gets sent to the LLM.
• test more scenarios, like tools with job attachments and so on
• clean up implementation, add more error checking, fix linting
• add and fix existing tests

[valentinabojan]

On what usecase we can end up without a tool call id?

[andreitava-uip]

In our Agent loop? None because we always do routing via Send(), or the guardrail subgraph which has the tool_call_id in the state (because it was called with Send() )
But if somebody else tries to reuse our primitives anyhow and they don't respect our contract, the id can be missing

[valentinabojan]

This function is generic for any scope (agent, llm or tool). Won't your changes add the TOOL_CALL_STATE_HANDLER for agent and llm guardrail subgraphs as well?

[andreitava-uip]

it would, but the llm and agent subgraphs are expected to have tool_call_id=None, which will make the node a no-op.
We can of course also conditionally add this node only for tool guardrails, that would make it more optimized.