Refactor DebugStackTrace into separate AOT and JIT versions

_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](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net8plus%2Cwindows#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.