Enable restore for ref and src projects in libs

[ViktorHofer]

Second attempt of #33242

Fixes #29953
Contributes towards #31844

Changes

• Use RestoreUseStaticGraphEvaluation which improves no-op restore by 10-15x down to 10-20 seconds.
• .builds msbuild files renamed to .proj as RestoreUseStaticGraphEvaluation throws for non .proj files without an env var set.
• Introducing subsets for libraries and mono and replacing -buildtests switch which was only working for libraries in favor of the subset switch -subset tests which works consistently.
• Fixing the Microsoft.DotNet.CodeAnalysis analyzer which wasn't running and adding missing exclusions.
• Separating restore and build phases in different parts in the repo (ie for installer.tasks) as generated props and targets need to be imported which requires a reevaluation in the build phase.
• Fix eng/docker/build-docker-sdk.ps1 by using the official build entrypoints (cc @alnikola)
• Remove a few depprojs in favor of project restore (faster restore :))
• Fix root code coverage measurement not working correctly
• Traversal support instead of dir.traversal.targets or manual build target defines.
• Introduce a root Build.proj entrypoint which is responsible for building and restoring the repository. This is necessary to enable the new NuGet fast restore which works best and fastest with a single entrypoint.
• Avoid binclashes in libraries and between libraries and installer (netstandard.depproj vs netstandard.csproj)
• Upgrading the SDK to 5.0 latest
• Code cleanup

Perf

In most cases I see improvements in the overall restore but based on it hitting the network the numbers vary slightly accross builds. That said, this should provide confidence that the regression introduced in the previous attempt is now addressed.

Thoughts on the numbers:

• Overall restore is either on parity or faster. This is because of a) a single entrypoint to restore and b) fast restore mode enabled.
• No-op/Incremental restore is MUCH faster. Incremental restore takes up to 90% less time with NuGet Fast Restore Feature.
• Libraries Test Builds should be noticeably faster in CI as it just restores what it needs.

Leg	Build&Restore Before	Build&Restore After
Mono Product Build Linux arm release	6m 55s	4m 45s
Mono Product Build Windows_NT x64 debug	4m 0s	3m 58s
Libraries Build Linux x64 Debug	12m 18s	12m 18s
Libraries Build OSX x64 Debug	8m 53s	9m 10s
Libraries Build Windows_NT x86 Release	15m 24s	13m 22s
Installer Build and Test Linux_musl_arm64 Debug	11m 52s	5m 34s
Installer Build and Test OSX_x64 Debug	8m 29s	8m 36s
Libraries Test Build Linux x64 Debug	8m 37s	7m 30s

Compared https://dev.azure.com/dnceng/public/_build/results?buildId=582003 with https://dev.azure.com/dnceng/public/_build/results?buildId=583335 and looked into other builds as well to make sure that the before numbers aren't a best or worst case.

cc @jeffkl @ericstj

[ViktorHofer]

Queued an official build: https://dnceng.visualstudio.com/internal/_build/results?buildId=589912

[ViktorHofer]

Failure is #30056

[ViktorHofer]

Internal build succeeded and all previous public runs were green. Merging.