Analyzers prototyping - Instrumentation module

[JanKrivanek]

Context

#9627

This module will handle monitoring and summarization of overhead added by analyzers infrastructure and individual analyzers (will be usefull during build performance investigation). API is yet to be determined but sample is added for illustration

Things to be investigated and decided

• We should have opt-in-able output in binlogs, but do we maybe want to trace to ETW as well? (we can leverage the Microsoft.Diagnostic.Tracing to facilitate the collectiong and just have custom events consumer)
• Multiple nodes processes considerations
• Roslyn current implementation and what can we reuse (https://github.com/search?q=repo%3Adotnet%2Froslyn%20ReportAnalyzer&type=code)

Possible tracing API

    public struct ScopeId { }

    public static class Tracing
    {
        ScopeId RegisterScope(string name, ScopeId? parent) { }
        IDisposable EnterScope(ScopeId scope) { }
        void ExitScope(ScopeId scope) { }
        TracingSummary GetSummary() { }
    }

[JanKrivanek]

Some isnpiration from the Roslyn implementation:

> dotnet new console
> dotnet build /p:ReportAnalyzer=true /bl
> .\msbuild.binlog

We do not have to necessarily be same level of detail or structuring in binlog in the V1, though.

We can just flush the stats as a single message or a series of messages, and then have a separate workitem for making those better organized in the Binlog Viewer (similarly as the Roslyn stats have a special case presentation logic: https://github.com/KirillOsenkov/MSBuildStructuredLog/blob/4116c37b386613684c270893f2d0a606f82b465d/src/StructuredLogger/Analyzers/CscTaskAnalyzer.cs#L9)

[baronfel]

Consider the use of System.Diagnostics.Activity here instead of Tracing directly - a lot of the runtime/tooling have embraced Activities as a more convenient and user-accessible way of tracking not only the duration of a unit of work, but also metadata for that unit of work that might be useful (a la structured logging!) and the parent/child relationships of that unit of work to other units of work. This level of instrumentation is pretty common in our (MS) application frameworks and libraries now. We've got some conceptual docs for it here, and I'm happy to talk more about it - we're making pretty big bets on it BCL-wide.