MSBuild should publish a library that helps tools interact with Solution files and other container-ish project types

### Summary

.NET Tooling teams have to work with solution files, it's a fact of life. While the _format_ now has a good serialization library, the format needs massaging in order to correctly make use of the data in MSBuild, either from the MSBuild CLI or via the MSBuild APIs. This massaging is not exposed to users, so they resort to reflection or duplicating code to approximate the same behaviors MSBuild has when interacting with solutions. We should make this knowledge publicly-accessible, but do so in a way that is easier for us to support.

### Background and Motivation

Today the MSBuild engine understands how to work with solution files when performing a build. It can read their contents, interpret the various solution configurations, and generate a _metaproject_ - a kind of buildable representation of the Solution that applies the various Solution-level Configurations metadata to the Projects contained inside the solution. MSBuild also has knowledge about the kinds of projects inside the solution that is useful with programmatically interacting with the solution - namely if a given Project is _buildable_ or not.

Tools that do not directly build solutions often need to interpret it to get information about how to interact with a given project - `dotnet test` is a good example. After the solution has been built, the `test` command needs to know how to evaluate a Project (or even if it _should_ evaluate a given project) so that the data it reads about the OutputPath and Run Arguments aligns with the output that MSBuild just built. This is _very difficult_ to do today. See dotnet/sdk#51398 for an example.

### Proposed Feature

We should provide a new API, independent of the SolutionFile today, that
* accepts a SolutionPersistence.SolutionModel as input
* performs most of the pre-parsing and manipulation that happens in the `SolutionFile.ReadSolutionModel` and `SolutionProjectGenerator.Generate` methods
* returns this information as a new kind of data structure not coupled to the MSBuild Construction APIs or MSBuild Project Object Model
* can be used to simplify the implementation of the `SolutionProjectGenerator`
* can be used by other tooling like `dotnet test` to easily answer the questions
* Is this project buildable at all?
* how should I evaluate/build this project (primarily meaning global properties, but may also have other aspects)
* ideally is available in a standalone library to prevent dragging in the huge MSBuild dependencies.

### Alternative Designs

_No response_