Part of #1955

This uses Diagnostic IPC to connect to the CLR in-process, capture Microsoft-DotNETCore-SampleProfiler trace events and transforms them to the format Sentry understands.

In its current state, the feature is in a good shape for alfa testing but there's a major followup to resolve and that is how TraceLog, which is a tool to process raw events and get figure out stack traces, works, i.e. that it requires files and needs to be saved & then loaded from file to be actually usable (see here). I'm starting to lean towards a fork/copy of relevant parts where we gut it to get what we need and drop the rest. That way we could also do without the rundown provider that gives as all past .net runtime events when we start a profile. Functionally (from the user perspective), the profile should look the same, but the implementation should be more efficient than it is now, especially the processing that happens after the profiling stops and also it would be most noticeable for short transactions if we could avoid requesting all past CLR runtime events (for simple app, it's about 3 MB of data).

TODOs

• test full SDK setup & finish right after a transaction is finished to make sure the processing is waited-for in the BackgroundWorker FlushAsync() and the profile appears in the envelope.
• handle exceptions gracefully
• limit long running transactions (30s)
• maybe make processing asynchronous, or run the whole thing on a different thread
• fix to support interleaving transactions
• downsample during processing (currently downsampled while converting nettrace to ETLX)
• configure in-app

Followups

• maybe filter-out threads that don't run any user code? marked as in-app=false
• should we filter-out sentry-specific/profiling-specific samples? marked as in-app=false
• provide debug_meta images if we want to show line numbers - this may need to be opt-in as it will likely add some runtime overhead
• downsample during ingest, if possible - currently, the runtime samples at 1000 Hz (1 ms) without any way to configure that yet, but we want it to be closer to 101 Hz - we should be able to filter samples directly in the _session.EventStream before even transforming to ETLX.
• filter out repeating stack_id for a given thread (i.e. don't send new timestamps unless the stack trace changes) - this may be a follow-up and should also be considered for other SDKs because it may significantly reduce the payload size in multithreaded environments. For example, this thread could be significantly reduced: https://sentry-sdks.sentry.io/profiling/profile/sentry-dotnet/3f359ed615d94111bd927e821917d1c8/flamechart/?colorCoding=by+symbol+name&query=&sorting=call+order&tid=2&view=top+down&xAxis=transaction
• it may be possible to handle GCstart & GCend events to show garbage collection
• collect Microsoft-Windows-DotNETRuntime rundown provider (loaded libs, etc) in a separate session and merge with actual samples later during processing, if possible (merging nettrace files, or having a custom provider for TraceLog).
• Or maybe we don't even need to collect these because we're in the same process? can we hack our way around and get the libraries from the current process instead? Probably not so easy because it also somehow stack walking if I'm not mistaken.
• Get rid of writing the intermediary files if at all possible - doesn't seem to be doable at the moment, raised Create TraceLog (ETLX) without writing to file microsoft/perfview#1829
• Figure out thread names (we only have native thread IDs though so it seems to be a problem)
• Consider capturing only the current "activity", i.e. not all threads but only what belongs to the transaction.
• profile & optimize the capture and processing