Add support for writing EventPipeEvents to ProfAPI

[mjsabby]

This augments the EventPipe framework to send data to the Profiler APIs in addition to any other receivers that may be configured.

This change does not add or remove any requirement on how the eventing system is initialized. Although it does provide a provision to the Profiler APIs that despite whatever the eventing system may be initialized to, it can eject itself when it needs to.

[mjsabby]

@brianrob @noahfalk

[discostu105]

I'd also be interested in that feature. Talked about something similar a long time ago in #4382 (route GC ETW events directly to profiler to avoid NT kernel roundtrip).

[georgschausberger]

Is there any update? I'm highly interested into this too!

[mjsabby]

I met @noahfalk recently, he can confirm the status, but I've asked it be at least considered for 3.0, given at least one implementation works (although it may not be the final one).

Can you (@discostu105 @georgschausberger) describe your scenarios? Is it just for GC events or would you like all the events so that if you were building a monitoring tool a lot more can be gleaned with preexisting runtime instrumentation vs. for example you adding your own instrumentation via IL rewriting?

[georgschausberger]

@mjsabby the main purpose is building a monitoring tool which should be able to use all kinds of events. Furthermore synchronous events would be much appreciated to have a chance of thread affine time tracking.

[davmason]

Closing this in preparation for repo consolidation.