[`/DELAYLOAD`](https://learn.microsoft.com/en-us/cpp/build/reference/delayload-delay-load-import?view=msvc-170) only works with exported functions, not variables (as it patches thunks after the first load).
So instead of using exporting a pointer for `___tracy_RtlWalkFrameChain`, make it a function that will call said pointer. This only adds a `mov`+`jmp` instructions in optimized builds to the call, which is negligible compared to the actual cost of RtlWalkFrameChain. This also does not affect the reported callstack since it will use a `jmp` without touching the stack, so `___tracy_RtlWalkFrameChain` won't appear in the capture stacktrace.
This fixes usage with TRACY_HAS_CALLSTACK undefined, allowing compilation of
otherwise unused functions, which are already protected from being called
through macro redirections.
See https://github.com/wolfpld/tracy/pull/492 for more information.
Initializing structures for callstack processing (building memory map of the
process, gathering kernel symbols, etc) takes some time, which in some cases
may be significant.
Callstack queries are now handled on a separate thread. In such setup it no
longer makes sense to block main thread execution with this lengthy init
process.
All the heavy initialization phase has been now moved to this separate
processing thread. Some initial callstack queries may now not produce
responses as promptly as before, but this is only because the main thread is
able to start working earlier.
Some parts of the initialization process may be critical to do in the main
thread, for example because the function responsible for gathering callstacks
must be loaded first. This is done still on the main thread, in a new function
InitCallstackCritical().
