Improve stack trace consistency for generic types across runtimes

[medhatiwari]

Summary

This PR addresses 4 out of 6 stack trace formatting issues identified in #63927 by enhancing StackTraceHelper to provide consistent generic type parameter display across different .NET runtimes.

Problem

As documented in #63927, StackTraceHelper tests fail on Mono due to differences in how generic type parameters are represented in stack traces compared to CoreCLR:

CoreCLR (expected):

GenericMethod<T>(T value)
GenericClass<T>.Method(T parameter)  

Mono (current):

GenericMethod<string>(string value)        // Shows concrete types
GenericClass<int>.Method(int parameter)    // Shows concrete types

Solution

This PR implements three targeted improvements using standard .NET reflection APIs:

1. Generic Type Definition Resolution

Uses Type.GetGenericTypeDefinition() to ensure declaring types show parameter names instead of concrete types.

2. Generic Method Definition Resolution

Uses MethodInfo.GetGenericMethodDefinition() to show generic parameter names in method signatures.

3. Method Parameter Type Resolution

Uses methods from generic type definitions to ensure parameter types show generic names.

Tests Fixed

This PR resolves 4 out of 6 failing tests from #63927:

1. StackTraceHelper_PrettyPrintsStackTraceForGenericMethods
2. StackTraceHelper_PrettyPrintsStackTraceForMethodsWithGenericOutParameters
3. StackTraceHelper_PrettyPrintsStackTraceForMethodsOnGenericTypes
4. StackTraceHelper_PrettyPrintsStackTraceForMethodsWithGenericRefParameters

Remaining Issues

Two tests from #63927 are not addressed in this PR:

5. GetFrames_DoesNotFailForDynamicallyGeneratedAssemblies

Issue: Lambda method naming inconsistency

• CoreCLR: "lambda_method34(Closure )"
• Mono: "object.lambda_method34(Closure )" (includes declaring type prefix)

Potential approach: Detect dynamically generated methods and strip the declaring type prefix from method names when present.

6. StackTraceHelper_ProducesReadableOutput

Issue: Async state machine resolution for generic methods

• Expected: "MethodAsync<TValue>(TValue value)"
• Mono: "<MethodAsync>d__14<TValue>.MoveNext()" (state machine not resolved to original method)

Potential approach: Enhance state machine resolution with name pattern fallback that parses state machine type names to find the original async method, with special handling for generic method overloads.

Question

Should the remaining two issues be addressed in this PR by adding the workaround approaches described above, or does this need to be fixed in the runtime?

cc: @giritrivedi

[medhatiwari]

@captainsafia can you please look into merging this