Produce a smaller SDK

The SDK could be a lot smaller. A smaller SDK would significantly benefit CI and similar environments. We typically think of the SDK being installed on a developer machine, being persistent there, and only be updated once/month (at most). I'm guessing that most SDK installs are not in persistent but disposable/temporary environments.

We're always looking for ways to reduce the size of containers. The fewer bytes we transmit over the wire, the better. The size difference between compressed and uncompressed SDK sizes is telling. The compression is very good.

Related issues:

- https://github.com/dotnet/sdk/issues/16895
- https://github.com/dotnet/dotnet-docker/issues/5474

I propose we do the following:

- Remove the unused assemblies by doing RID-specific SDK builds.
- Removing all the duplicate assemblies, via some kind of sharing mechanism (which might require help from the runtime team).
- Establish multiple supported layers of the SDK.

On the last point, I'm interested in producing two different flavors of the SDK in containers, a core layer and a tools layer. Perhaps there are other splits that would be more compelling / complementary.

For containers, I'd see a lot of value in having a `-tools` layer that contained all the existing `dotnet-` tools, like `dotnet-watch` and additional tools like `dotnet-trace` and also move PowerShell to that layer. It could be equally interesting to make `dotnet-*` tools available in a layer on top of `aspnet` but that's a different topic.

My hypothesis is that we can reduce > 50MB of compressed size from our SDK container images (for the core layer), with no loss of functionality for typical needs. That would be huge.

Ideally, we can do this for .NET 10.