Provide a mechanism for supporting earlier .NET SDKs with platform-specific .NET tools

### Is your feature request related to a problem? Please describe.

The introduction of platform-specific .NET tools in .NET 10 preview 6 and preview 7 is great, and provides the nice capability for producing self-contained and native AOT tools. However, these rely on Version 2 of the DotNetToolSettings.xml file, which is _only_ supported on .NET 10.

Because the "meta" package also requires version 2, there's no way to use these packages for customers that have previous SDKs installed. So .NET Tool authors are stuck with a choice: provide maximum compatibility, and produce a framework-dependent package, or _only_ support the .NET 10+ SDK, and get the benefits of the other packages.

As a tool author that's concerned about compatibility, this likely means I will never be able to adopt the new capabilities.

### Describe the solution you'd like

_Ideally_ it would be possible to have the best of both worlds: maximum compatibility for customers on <.NET 10 SDK, and maximum performance for customers on the .NET 10 SDK.

I think there's a middle ground that can be found, similar to the following:
- Produce the platform-specific packages as we do today in .NET 10
- Produce the root "meta" package that points to each of the platform-specific packages
- Ensure that the _DotNetToolSettings.xml_ file is placed in the `tools/net10.0` folder (instead of the `tools/` folder as it is today
- Allow optionally packaging one or more framework-dependent platform-agnostic instance of the app in `tools/net5.0` (or whatever tfm is required)

This isn't _ideal_ because the root package gets larger, but it has the advantage of actually being usable in earlier SDKs. Unfortunately, unless Version 1 of DotNetToolSettings.xml supports the "delegating" approach, I'm not sure there's a truly optimal option.

### Additional context

I manually hacked together a package that does the above:

You pay the size-cost of a single TFM in the root package, but then the platform-specific package can be native aot compiled (for example):