Proposal: Strong Typing for CallTool

Is your feature request related to a problem? Please describe.
Currently the CallTool function only handles text output well.
If the Caller expects a specific type e.g. map[string]int or a struct then the Caller has to workaround the current state of the SDK.
This leads to unnecessary CPU and Memory Consumption and that despite of the server side of the SDK handling this scenario so well.

Describe the solution you'd like
There is a variant of my request with and without generics
Without generics, the CallTool function would allow to specify the output reference e.g.
CallTool(..., output any) error
The SDK would then directly unmarshal into the output reference.

Describe alternatives you've considered
So above is not a show stopper, as a workaround exists

Additional context
Here my workaround code:

	result, err := session.CallTool(c.context, &mcp.CallToolParams{
		Name:      toolName,
		Arguments: input,
		Meta:      mcp.Meta{"progressToken": progressToken},
	})
	if err != nil {
		return err
	}
	if result.IsError {
		var errMsg string
		for _, content := range result.Content {
			if tc, ok := content.(*mcp.TextContent); ok {
				if errMsg != "" {
					errMsg += "\n"
				}
				errMsg += tc.Text
			}
		}
		if errMsg == "" {
			errMsg = "tool call failed"
		}
		return errors.New(errMsg)
	}

	if output == nil {
		return nil
	}

	var textContent *mcp.TextContent
	for _, content := range result.Content {
		if tc, ok := content.(*mcp.TextContent); ok {
			textContent = tc
			break
		}
	}

	if textContent == nil {
		return errors.New("unexpected content type in tool result")
	}

	if output != nil {
		if err := json.Unmarshal([]byte(textContent.Text), output); err != nil {
			return err
		}
	}

Needless to say, I dont like it.

Start at the CallTool entry point in the Go SDK and trace how tool results and TextContent are handled. Compare the proposed output-reference and generic variants, then define the supported typed-output behavior and verify it with the SDK's existing tests; done means callers no longer need the shown JSON unmarshal workaround.