Convert genRuntimeEventSources.py script to msbuild task

[ViktorHofer]

Initial cost estimate: 2 man-weeks
Initial contacts: @ViktorHofer, @trylek

In response to #688, we should remove the python dependency from the build and a good starting point for that would be the event source file generation in CoreLib. This should be done via an msbuild task (installer.tasks) as pure msbuild presumably isn't powerful enough.

Also note that #39052 (comment) indicates that the msbuild task should also have a boolean to allow stubbing the event source file out for new OS bring-up.

@jkotas for new device/OS bring-up, how does CoreLib itself get compiled without msbuild (as the discussion in the other thread suggested that msbuild might now work initially)?

cc @dotnet/runtime-infrastructure (coreclr folks especially)

[akoeplinger]

In response to #688, we should remove the python dependency from the build

note that the Mono portion of the build uses python too, so if you want to remove it completely we should coordinate that.

[ericstj]

This could also be done with a C# source generator.

[hoyosjs]

The file used to generate the events is a manifest, and it generates native headers and c sharp code. Not sure if source generators are the best bet here given we don't need as much information on the c# side (might be worth thinking about it though with the portable thread pool).

[ericstj]

There is a scenario in the cookbook that maps to this: https://github.com/dotnet/roslyn/blob/master/docs/features/source-generators.cookbook.md#additional-file-transformation

it generates native headers and c sharp code

I noticed that https://github.com/dotnet/runtime/blob/master/src/coreclr/scripts/genRuntimeEventSources.py generated C# but I didn't see the native headers. Agree that if you need to generate native headers C# source generator isn't appropriate.