Helper method to merge additional metadata into requests, results, and notifications

[mikekistler]

Motivation and Context

This PR adds a helper method to the RequestParams, NotificationParams, and Result classes, all of which have a Meta property, that will merge additional metadata into that Meta property.

This was motivated comments on #970 but is a standalone feature that can be done in its own PR.

How Has This Been Tested?

Will add tests.

Breaking Changes

Not breaking.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[mikekistler]

@stephentoub @PederHP Is this what you had in mind when you suggested a helper method to merge metadata into an existing request / result / notification?

[PederHP]

@stephentoub @PederHP Is this what you had in mind when you suggested a helper method to merge metadata into an existing request / result / notification?

Yes, exactly.

[stephentoub]

We're needing to duplicate this method into each place that has Meta. We're also baking in the overwrite semantics of the additionalMeta always winning, as opposed to an existing value winning. If this is common enough to need a helper for, should we instead expose a static merge method?

@eiriktsarpalis, are we missing something here in STJ? What do you think we should do?

[halter73]

Can we put this logic into an internal shared method?

Also, do we want to do a deep merge? For example,

// Left
"_meta": {
  "a": {
    "b": {}
  }
}

// Right
"_meta": {
  "a": {
    "c": {}
  }
}

// Deep Merge
"_meta": {
  "a": {
    "b": {}
    "c": {}
  }
}

With the current shallow merge, the right JsonObject would completely overwrite the left one. This might be the best behavior if we don't think it makes sense for multiple components to configure the same top-level _meta keys, but we should at least clarify this is a shallow merge in the doc comments.