Optimize `stacktrace` by avoid large allocation

[AlexGuteniev]

achabense observed that pre-initializing internal vector in stacktrace to the maximum possible depth has noticeable performance impact:

STL/stl/inc/stacktrace

Line 142 in 2261f7e

basic_stacktrace _Result{_Internal_t{}, _Max_frames, _Al};

STL/stl/inc/stacktrace

Line 303 in 2261f7e

static constexpr size_t _Max_frames = 0xFFFF;

The CaptureStackBackTrace API does not have a way for determining the needed amount in advance.

Currently we don't maintain own array management in stacktrace and using vector to avoid dealing in one more place with:

• copying/moving/assignments
• allocators
• ASan

What could we do:

• Alex Guteniev (@AlexGuteniev) suggested that we can create a secret constructor for vector without initialization.
• Stephan T. Lavavej (@StephanTLavavej) suggested we can use smaller allocation on stack, and then try maximum if smaller overflow, otherwise copy data from the stack and not allocate large amount. Smaller could be 32 entries, which is 32*sizeof(void*) bytes,
• nicole mazzuca (@strega-nil-ms) suggested we could start with smaller allocations and grow in a geometric progression

[frederick-vs-ja]

• Stephan T. Lavavej (@StephanTLavavej) suggested we can use smaller allocation on stack, and then try maximum if smaller overflow, otherwise copy data from the stack and not allocate large amount. Smaller could be 32 entries, which is 32*sizeof(void*) bytes,

See also #3850 (comment). It seems desired to introduce an internal small_vector-like container.

[AlexGuteniev]

An user suggested that we can use thread_local buffer as a temporary storage. Can we?

[StephanTLavavej]

On Discord, I mentioned that thread_local drags in TLS, which is problematic for users like Windows (which is why we avoid Magic Statics throughout the STL). Putting that into the import lib would be a recipe for headaches, so I think we need to avoid that.