Expose project evaluation metrics via System.Diagnostics.Metrics

[OvesN]

Fixes #14419

Context

Project evaluations initiated directly through the MSBuild object model are not necessarily visible to the binary logger attached to a later build. Hosts need a low-volume way to measure evaluation count and duration without requiring every caller to add custom instrumentation.

Changes Made

• Add the process-local Microsoft.Build meter with msbuild.project.evaluations and msbuild.project.evaluation.duration instruments.
• Tag measurements by requested evaluation stage, build-submission versus standalone origin, and success.
• Keep the disabled hot path allocation-free and prevent instrumentation or listener failures from affecting evaluation.
• Declare and unify System.Diagnostics.DiagnosticSource for .NET Framework hosts.
• Document the metric contract and add coverage for every evaluation stage, origin classification, failures, listener resilience, and duration on .NET and .NET Framework.

Testing

• Full repository build: passed with 0 warnings and 0 errors.
• Evaluation metrics tests: 8 passed on net10.0 and net472.
• Bootstrap sample build and MSBuild help invocation: passed.
• Full Release test suite had three environment-only failures: two shared debug-log cleanup races and one test where msbuild was absent from PATH. The affected Framework class, full OM net472 suite, and portable-task test all passed when rerun individually.

Notes

MSBuild exposes the meter but does not configure an exporter or send measurements. Collection remains the responsibility of the host or diagnostic tooling. Metrics are process-local, so consumers must subscribe in each SDK, server, or worker process they need to observe.