Stack traces with async variants

[MichalStrehovsky]

The stack trace metadata would likely only have information about the thunk, not about the the calling method.

So doing DiagnosticMethodInfo.Create(new StackFrame()) in a runtime async method will likely return no information. We need to swap IsAsyncCall bodies for thunks when emitting stack trace information.

Also figure out what CoreCLR does for new StackFrame(1) (i.e. asking for the thunk).

From @davidwr This is also an issue for the coreclr interpreter, as it needs a helper function, which is defined in C#, and there is no way to disable that either.

[dotnet-policy-service]

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

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• new StackTrace() inside async methods -> Useless, Lack of frames with sync caller method (initiator) #60764

[VSadov]

Also figure out what CoreCLR does for new StackFrame(1) (i.e. asking for the thunk).

Seems like CoreCLR skips thunks. (skips resume stubs too). #122517 (comment)

[davidwrighton]

@VSadov This is also an issue for the coreclr interpreter, as it needs a helper function, which is defined in C#, and there is no way to disable that either. I don't think that this test is a good idea. We can fairly easily remove the thunks from the Exception ToString, etc, by using [StackTraceHidden], and I'll do that, but the StackFrame api doesn't have that flexibility.

[jkotas]

Fixed by #122722