Add function for users to set extra TLS needed before calling threading APIs

[trustytrojan]

Reason for this PR

When building libcurl with CURL_DISABLE_VERBOSE_STRINGS set to OFF (verbose strings enabled), all of the internal debug printf calls (macro'd to libcurl's internal printf implementation, NOT newlib), to my understanding, have their format strings copied to static memory (which can be TLS?). However when making an HTTP request under a Calico non-main thread, many different crashes occur at different addresses. The only time addr2line gave me a proper file:line number, it pointed to here, where the format string is trying to be read. So I theorized that the thread doesn't have enough memory, changed this line to have + 1024 in the expression for needed_sz, and no crash occurred.

Changes

• Added void threadSetPthreadExtraTls(size_t) to allow applications to set any extra TLS needed (will be 8-byte aligned) for the next created POSIX/C/C++ thread.
• Added static size_t extraTls to be able to store the extra size needed from the function above.

[fincs]

What is the actual bug that is causing a buffer overrun in curl? This "fix" really does not seem appropriate, applications shouldn't need "extra" tls space beyond what is actually declared.

[trustytrojan]

I can't pinpoint the exact printf call that libcurl causes the crash with. As far as I know all their macro'd printf calls do use string literals as the format strings. All the information I have is the while (*fmt) { ... fmt++; } linked before, which only tells me it's reading out of bounds. However I can't change the code because the size of fmt is never given, and returning/breaking early causes more problems.

Yes, I do think this is very odd: format string literals are supposed to be in static memory, I have no idea why this goes out of bounds, no matter which thread its running in.

You can close this PR or turn it into a draft if you'd like. I was just pitching the idea in case this would be useful for other applications. The fix for me is not using curl's verbose debug output when threading.