msvc-based stacktrace should also allow to determine the module image path

The current msvc-based stacktrace only determines the module name - not its complete path - contrary to the full featured unixoid implementation. It turns out that this is rather simple to realize and valuable when attempting to analyze application problems by inspecting the referred to image paths. It means that you first calls [IDebugSymbols::GetModuleByOffset](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugsymbols-getmodulebyoffset) followed by [IDebugSymbols::GetModuleNames](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/dbgeng/nf-dbgeng-idebugsymbols-getmodulenames) using the `ImageNameBuffer`, `ImageNameBufferSize`, and `ImageNameSize` parameters. I'm using this extended information in my own stacktrace implementation.

There is another way of improving the quality of msvc stacktraces related to the problem described [capturestackbacktrace-randomly-fails-after-initial](https://developercommunity.visualstudio.com/t/capturestackbacktrace-randomly-fails-after-initial/1383213). I'm aware that the current stacktrace implementation has eliminated any explicit call of `CoInitializeEx`, but that does not prevent the user to make such a call. Instead of rewriting `RtlCaptureStackBackTrace` as suggested in this article, a very simple workaround seems to help here. Before calling `RtlCaptureStackBackTrace` with a static buffer (128), just call `RtlCaptureStackBackTrace` with the `FramesToCapture` equal to just `1` ignoring this stub call, which prevents the potential empty stacktrace situation for the second call.

Would there be interest for a corresponding PULL request?

首先定位基于 MSVC 的 stacktrace 实现，并了解它目前如何确定模块名称。检查 IDebugSymbols::GetModuleByOffset、GetModuleNames 和 RtlCaptureStackBackTrace；当包含模块映像路径，并且处理了报告的空 stacktrace 情况，同时没有破坏现有的 stacktrace 行为时，即视为完成。

由索引模型根据 Issue 内容生成。