Don't use the new parser from Microsoft.VisualStudio.SolutionPersistence to parse .sln files.

Fixes #11463

Work item (Internal use): AB#2397817

Summary

Revert #10836 to return to the longstanding MSBuild private .sln parser (but keep using the SolutionPersistence library for .slnx).

Customer Impact

Three categories of problem:

• Some older NuGet.exe restores failed because they couldn't find the library (fixed in newer versions but reported via VS Feedback and Update to msbuild 17.13 breaks builds microsoft/dotnet-framework-docker#1213.
• Current NuGet.exe restores can fail if the path to 64-bit MSBuild is specified explicitly
• Various bugs in the solution parser (e.g. MSBUILD 17.13.9.7704 MSB4025 microsoft/vs-solutionpersistence#96) that don't hit in the legacy MSBuild parser.

All manifest as build or NuGet restore breaks with no obvious workaround (but once discovered the changewave opt-out environment variable works).

Regression?

Yes, in 17.13/9.0.200 due to adopting the common SolutionPersistence library instead of our homegrown sln parser.

Testing

Unit tests + manual scenario tests.

Risk

Low, clean revert to earlier behavior for .sln.