Consider matching ETW to fire the new events added to EventPipe

[LakshanF]

For new events added to NativeAOT, we are prioritizing enabling these via EventPipe given that its cross-platform (see PR #87785 for an example). Getting events via EventPipe is our primary focus, and tools like PerfView can see these events with enabling the relevant providers (for example, Microsoft-DotNet-Runtime provider). But given that ETWProvider has been supported in .NET7, we should strive to add the new events to be enabled via ETW as well.

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

For new events added to NativeAOT, we are prioritizing enabling these via EventPipe given that its cross-platform (see PR #87785 for an example). Getting events via EventPipe is our primary focus, and tools like PerfView can see these events with enabling the relevant providers (for example, Microsoft-DotNet-Runtime provider). But given that ETWProvider has been supported in .NET7, we should strive to add the new events to be enabled via ETW as well.

Author:	LakshanF
Assignees:	LakshanF
Labels:	area-NativeAOT-coreclr
Milestone:	8.0.0

[elinor-fung]

Another aspect of this is that the GC events already emitted via ETW in .NET 7 are emitted regardless of whether or not EventSource support is enabled.

Would we want the same behaviour for these other events? That seems to go against the desire to strip out anything unnecessary in NativeAOT / make things opt-in, but it would also be weird to always have only (a subset of) GC events and require enabling EventSource support for the other runtime events. Or they could all be switched to opt-in - but I'm not sure what existing scenarios may rely on the existing ETW events being non-opt-in.

Keeping the ETW events as always on makes for a lack of consistency/parity cross-plat (in addition to going against our desire for minimalism in NativeAOT). I'd think that ETW event support belongs in the same category as EventPipe support - in which case it would be opt-in.

[LakshanF]

We have done work to make this easier (see above merged PRs) but doing this in .NET9 seems ok given our aim for .NET8 is for basic functionality.

[LakshanF]

We now use gen-eventing-event-inc.lst as the allowed events for both EventPipe and ETW