Refactor and improve MLL tests (#66332)

Refactor and improve MLL tests (#66332)

* Remove duplicated code - I know that tests should be descriptive, but repeating 100 times that we want to capture output doesn't feel necessary.
* For some of them move more stuff into the shared test state - this improves perf as we avoid repeating the setup (copying files around) for each test case, we do it once for the entire class
I also changed some of the tests to "Theory" as it's easier to read that way.
  * `SDKLookup.cs` - moved most of the state in to the shared state to speed up the tests.

* Adding more cases into the "theory" tests
  * Most notably for the framework resolution I added variations on the TFM (which will be needed when we implement disable of MLL)
* Adding new tests mostly around "list runtimes" (various forms), "list sdks" (various forms) and errors (which also list runtimes or sdks)

* Ported all of the `MultiLevelLookupFramework` tests over to the `FrameworkResolution` and `DependencyResolutions` suites which have a more robust test infra and can run the same tests much faster. Along the way I added lot more variations on top of the existing tests:
  * `PerAssemblyVersionResolutionMultipleFrameworks.cs` - this is actually not an MLL test, but I moved it to the new infra to make it much faster
  * `MultipleHives.cs` - MLL framework resolution tests

For SDK resolution I kept the `MultiLevelSDKLookup.cs` just removed code duplication and added new variants.

For the core reviewers: I promise I didn't remove any single test case in spirit with these exceptions:

* We had tests which validated that framework resolution is not affected by frameworks in current directory and also by frameworks in the user's directory. I left some basic test for the current directory check, but I completely removed the user's directory variant as the product simply doesn't have any code around that anymore.

* Remove "user" directory from SDK resolution tests

The product simply doesn't have any knowledge about user directory SDK lookup, so there's little value in testing for it (even though the test expects it to not have any impact).

Co-authored-by: Elinor Fung <elfung@microsoft.com>