SseClientTransportOptions.Endpoint needs a way for a consumer to control if the corresponding Resource ends with a trailing slash or not

Bắt đầu bằng cách xác định SseClientTransportOptions.Endpoint và phần xây dựng URL ủy quyền được mô tả trong issue. Kiểm tra các bài kiểm thử hiện có về giao thức truyền tải SSE và các tham số tài nguyên OAuth. Công việc được xem là hoàn tất khi consumer có thể kiểm soát dạng dấu gạch chéo ở cuối endpoint và tài nguyên ủy quyền được tạo ra nhất quán với dạng đó.

Is your feature request related to a problem? Please describe.
When creating an MCP client that connects to an OAuth-secured MCP server, the "Endpoint" may have different conventions regarding whether or not it ends with a trailing slash. SseClientTransportOptions.Endpoint being a URI makes this increasingly problematic, as the default behavior appends a trailing slash, even if the input string doesn't contain it:

var urlRawString = "https://example.com";
var uri = new Uri(urlRawString);
		
Console.WriteLine(urlRawString); // https://example.com
Console.WriteLine(uri.ToString()); // https://example.com/

Per spec, this is even in violation of their recommendation of whether or not to include the trailing slash:

Note: While both https://mcp.example.com/ (with trailing slash) and https://mcp.example.com (without trailing slash) are technically valid absolute URIs according to RFC 3986, implementations SHOULD consistently use the form without the trailing slash for better interoperability unless the trailing slash is semantically significant for the specific resource.

Describe the solution you'd like
I'd like for SseClientTransportOptions.Endpoint to be a string, and the internals can validate that it is a URI

Describe alternatives you've considered
If SseClientTransportOptions.Endpoint being Uri is strictly necessary, than a callback to format the resource prior to constructing the authorization url may be helpful. Or some option to eab This is probably more problematic, though, as it would allow implementers to violate the spec more easily.

Additional context
To work around the issue, I have had to do the following when writing an MCP client:

1. Set ClientOAuthOptions.AuthorizationRedirectDelegate
2. Override the resource query parameter of the authorization url with the trailing slash removed