Extending the scope of the dotnet CLI with tools for the AI era

The .NET SDK is a monolithic package that includes a rich CLI. It is updated monthly via a rigorous process gates most changes. There are slower update trains with more liberal policies, however, they are slower. The pace of change has increased considerably, with AI agents often updating daily. We need to find a way to enable the most AI adjacent aspects of the CLI to ship on a fast schedule without much scrutiny.

It's reasonable to ask "what is this AI adjacent functionality that you speak of?". We currently have a catch-22 problem. Multiple team members have written AI-adjacent tools that they have published to nuget.org instead of "in box". It's not reasonable to ship AI tools in a slow moving box and consider them coherent when everything else is moving so quickly.

Proposed solution:

- Move the AI adjacent tools like [baronfel/mcp-binlog-tool](https://github.com/baronfel/mcp-binlog-tool) and [richlander/dotnet-inspect](https://github.com/richlander/dotnet-inspect) to dotnet/sdk.
- Ship AI adjacent tools via nuget.org.
- Wrap them in a [tools metapackage](https://github.com/dotnet/sdk/issues/52609)
- Update `dotnet tool` to make it easy to install and update tools metapackages.
- Expose tools and their capability via [dotnet skill](https://github.com/dotnet/sdk/issues/54243), largely an invitation to install the metapackage.
- Use these tools within [dotnet/skills](https://github.com/dotnet/skills) skills; no `dotnet-inspect` skill but perhaps a "generate API documentation on the fly" skill.

This plan solves a few problems:

- Establishes a pattern that we can use to deliver a broad set of tools.
- We can update them quickly, in response to user feedback, model updates, or conference talks.
- They become part of the Microsoft supply chain.
- We can advertise these tools broadly instead of being in the odd spot where employee-built personal tools are known and used only via the word-of-mouth marketing scheme.

Note: No to workload packs as a distribution mechanism. All other platforms use a NuGet-like analog, with NPM being top of the list. NuGet is pretty good and `dnx` builds on that, obviously modeled after `npx`. RID-specific tools are another good invention. An experience like [`dotnet-install`](https://github.com/richlander/dotnet-install) would take it a step further. Workload packs are not in this same realm nor are we likely to invest in it to make it as capable.