Revise McpClientExtensions to provide higher-abstracted APIs

[stephentoub]

It's useful that IMcpClient exposes the protocol layer, but the extensions that represent the majority use should represent the most convenient, integrated, idiomatic APIs we expect developers to consume, and for the 1% case, they can use the protocol layer. I think we should:

• Remove the cursor-based extensions and just have the ones that provide the full set
• Change the IAsyncEnumerable-based helpers to asynchronously return lists. We'd added the enumerable ones because they logically map to what's being done, however a) typically consumption isn't doing some with partial results such that an enumerable provides any latency benefits, b) enumerables can be a bit harder to work with, and most importantly c) every iteration of one of these enumerables is going to round trip to the server.
• Change the returned instances to be the most useful objects, e.g. instead of returning a Tool, return an AIFunction; instead of returning a Prompt, return a ChatMessage (maybe, needs investigating); etc.

[PederHP]

Prompt is at least conceptually more like a ChatMessage valued Func.

Agree that the "in-between" extensions are clutter that isn't necessary.

[stephentoub]

Prompt is at least conceptually more like a ChatMessage valued Func.

Yup, I intended to mean more for the result of getprompt.

[stephentoub]

Further addressing this can be done as part of #70 and #72. My expectation is those will result in mirroring what we have for McpClientTool and McpServerTool, with the client variants showing up in McpClientExtensions.