Allow function tool handlers to return errors

[rakyll]

This change re-introduces error as a possible return value for function tools. The previous removal of this feature led to poor error-handling patterns, as functions often need to signal failures from validation, I/O, or network calls. Restoring the ability to return errors allows for conventional error handling.

Fixes #260.

[baptmont]

Shouldn't we send the err to the llm when creating the summarization event? For example, modifying the examples/tools/multipletools/main.go if we have the function

	handler := func(ctx tool.Context, input Input) (*Output, error) {
		if input.LineCount < 3 {
			return nil, fmt.Errorf("invalid number of line count, the number of lines cannot be lower than 3 lines")
		}
		return &Output{
			Poem: strings.Repeat("A line of a poem,", input.LineCount) + "\n",
		}, nil
	}

The agent will never notify the user of the specific err:

[dpasiukevich]

It seems as @baptmont found we need to return an error string to llm err.Error(), otherwise if it's a pointer it won't read the error message.

[dpasiukevich]

It seems as @baptmont found we need to return an error string to llm err.Error(), otherwise if it's a pointer it won't read the error message.

Opened https://github.com/google/adk-go/issues/278 for that

[rakyll]

I wonder whether we should allow returning a response and an error at the same time. Then, the functiontool builder can choose between user visible error messages with their custom response type. From a quality perspective, we need to align the behavior with ADK Python. Let's follow up on the issue @dpasiukevich has created.

[hyangah]

We are already sending err to llm. Instructions need to tell llm what to do.