Refactor DebugStackTrace into separate AOT and JIT versions

[jamescrosswell]

_Originally posted by @vaind in https://github.com/getsentry/sentry-dotnet/pull/2732#discussion_r1368254953_

We don't have managed assemblies in AOT apps. See the Limitations of Native AOT deployment:

• No dynamic loading, for example, Assembly.LoadFile.
• Implies compilation into a single file

Conversely, we won't be loading native images in managed apps.

Currently our DebugStackTrace.cs files has dual functionality and abunch of switches/branches to load managed images and native images depending on what kind of app we're running.

The common functionality could be pulled out to a DebugStackTraceBase class with stuff like this:

• internal static DebugStackTrace Create(SentryOptions options, StackTrace stackTrace, bool isCurrentStackTrace)
• void MergeDebugImagesInto(SentryEvent @event)
• void DemangleAsyncFunctionName(SentryStackFrame frame)
• void DemangleAnonymousFunction(SentryStackFrame frame)
• void DemangleLambdaReturnType(SentryStackFrame frame)

The AOT/JIT specific methods and functionality within methods like those above could be pulled out to the concrete DebugStackTrace classes that could be compiled/included conditionally depending on whether we were compiling an AOT app or not.

[vaind]

AFAIK this is internal so it shouldn't have any breaking changes and thus doesn't need to happen in the 4.0.0 milestone - can we detach it or do you think it must be done now?

[jamescrosswell]

AFAIK this is internal so it shouldn't have any breaking changes and thus doesn't need to happen in the 4.0.0 milestone - can we detach it or do you think it must be done now?

Nah let's descope v4.0.0 as much as possible 👍🏻