Profiling blocks on short-lived threads 'leak' memory

[mathieumallet]

(Please excuse incorrect terminology as I'm not completely familiar with the inner workings of easy_profiler)

When an EASY_BLOCK is encountered in code, the following are done:

1. add a block descriptor for the block if one doesn't exist already
2. register the current thread if it isn't already
3. add a block of data to the current thread (if profiling is enabled)

However step 2 introduces an issue: if the EASY_BLOCK is encountered on a new thread, a new thread registration is done. This is fine (and wanted) when profiling, but when not profiling this results in threads being registered and kept in memory. If threads are constantly being created and destroyed, this results in increasing the memory usage over time.

This is what the allocation looks like in a profiler:

The thread registration data is removed when the thread has expired, but only when a capture is completed. If profiling is not enabled, that data stays in memory until the app exits.

Two possible fixes for this:

• add an EASY_END_THREAD macro -- this would be used with EASY_THREAD, and would tell easy_profile when it's safe to delete the thread registration data. this would be done only if a capture is not currently in progress (as otherwise we'd be losing profiling data)
• always detect when threads expire/finish (somehow) and remove the thread registration data at that time (again only if a capture is not currently in progress)

We have a fix for this in our own fork of easy_profiler (as a new macro to 'end' a thread), but this may not meet the quality requirements for the main easy_profiler repo: YOU-i-Labs/easy_profiler@v2.0.1-youi14...v2.0.1-youi14b