Optionally capture a dump during generational aware analysis

[cshung]

This change introduces an extra option to allow generational aware analysis to capture a dump in addition to the trace files.

The trace file contains information about the type of object that held the young objects alive, but very often, we also need to know the exact instance. This is particularly useful when the young objects are leaked by a delegate, where we would like to know which callback is causing the problem.

@dotnet/dotnet-diag

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This change introduces an extra option to allow generational aware analysis to capture a dump in addition to the trace files.

The trace file contains information about the type of object that held the young objects alive, but very often, we also need to know the exact instance. This is particularly useful when the young objects are leaked by a delegate, where we would like to know which callback is causing the problem.

@dotnet/dotnet-diag

Author:	cshung
Assignees:	-
Labels:	area-GC-coreclr
Milestone:	-

[noahfalk]

Looks fine to me, @mikem8361 you want to take a look as well?

[cshung]

@Maoni0, can you please approve the PR if the change is good from the GC's perspective?
@noahfalk, can you please take a look again? I made some refactoring to the underlying code since your last approval. The refactoring should make it easier to capture a dump without having to have an ifdef at the call site.

[Maoni0]

looks good from GC's POV.

[noahfalk]

Still looks good to me : )
(And thanks for the little refactor on GenerateDump)

[hoyosjs]

Dump changes and EP changes look like a cleanup to me :)