CArena: Implement alloc_in_place

[WeiqunZhang]

First we try to see if CArena has free space that can be used to extend the given pointer to the specified size range. If that's unsuccessful, we use the normal alloc function to allocate memory.

If in-place allocation is successful during vector resizing, we can avoid the cost of copying data to the new allocation address.

[WeiqunZhang]

@AlexanderSinn This new PR does not work with the memory profiling in TinyProfiler. Currently, we call TinyProfiler::memory_alloc to register memory allocation and TinyProfiler::memory_free to deregister. The issue now is the MemStat stored in m_busylist is associated with the first memory allocation that created the Node in m_busylist. Now, when we have additional memory alloations that extend a busy list's node, we need to find a way to store those extra MemStats. It's not clear how to do it. Make it a vector (std::vector<MemStat*>)?

[WeiqunZhang]

@AlexanderSinn Maybe we should de-register first and then re-register it. That would be the simplest approach.

[AlexanderSinn]

Yes, de-registering first and then re-registering should work fine.

It would be interesting to know from some sort of profiler or printout how often alloc_in_place succeeds.

However, because it is correctly de-register first, while with a normal resize the new allocation would be registered first before the old one is de-registered, TinyProfiler MaxMem should be smaller with this PR if alloc_in_place succeeds for the most expensive resizes.

[AlexanderSinn]

I tested alloc_in_place using HiPACE++ and it achieved a 36% success rate of all non-trivial cases. However, it only had a small impact on MaxMem of about 0.1% reduction (2 KiB). This is more or less expected since the function that resizes vectors has many small vectors and doesn’t use much memory in total anyway.