[Investigation] Evaluate TOON (Token-Oriented Object Notation) for token-efficient MCP tool results

## Context
Token cost of tool payloads is a growing concern, TOON is a compact, indentation + tabular serialization format that reduces tokens vs JSON for arrays of uniform objects. This is a spike to decide whether TOON has a place in the Azure MCP Server and how it fits the MCP spec.

## What we already know
- MCP is JSON-RPC 2.0 — the wire format can't be replaced with TOON.
- `structuredContent` / `outputSchema` results are JSON validated against JSON Schema — TOON can't be that payload.
- A tool result `text` content block is an opaque UTF-8 string, so TOON *could* be emitted there as a server↔model convention (not part of the spec).
- The tool catalog (`name`/`description`/`inputSchema`) is JSON Schema per spec, so TOON does **not** help the `tools/list` token cost.

## Questions to investigate
- On representative Azure MCP outputs (resource lists, log queries), how much token reduction does TOON give vs JSON — and vs Markdown/CSV tables?
- Do current hosts (GitHub Copilot, Claude, etc.) reliably parse TOON without a schema hint? Any accuracy regressions?
- Round-trip fidelity / edge cases (nested non-uniform arrays, escaping, nulls) — where does TOON lose its savings or break?
- Ergonomics: opt-in per tool, discoverability via tool description, and whether the ModelContextProtocol C# SDK content model makes this clean.
- Is there a simpler win (trim schema verbosity, Markdown/CSV tables) that captures most of the benefit with less interop risk?

## Deliverables
- Findings doc: measured token deltas on 3–5 representative payloads, host-compatibility notes, and a recommendation (adopt opt-in / don't adopt / revisit).
- If promising: a flag-gated prototype on one tool + a follow-up issue.

## Out of scope
- Any change to the MCP wire protocol or `structuredContent`/`outputSchema` (must stay JSON).
- Committing to a rollout — research only.