Initial-exec TLS variables do not work in the first thread

[nyh]

@benoit-canet discovered a bug in the way we run the init functions of a shared objects which has initial-exec (aka "static") TLS variables (and those are used by the init functions). This effects, for example, golang (see #522) programs, which uses both. But that is part of a more general problem with how we set up static TLS:

The program::get_library() function does not, and should not, create a new thread (only the osv::application wrapper does). One can load a library and call a function from it in the current thread, without creating a new thread.

The problem is that get_library() calls init_static_tls() which only changes the way that new threads will be created (when they will call setup_tcb()) - and does not modify the current thread's TLS area.

So in a program which uses static TLS (the initial-exec model), and runs code from the library without starting a new thread, it will not have access to its TLS variables.

In particular (and this is what led @benoit-canet to discover this issue), currently even using the osv::application API (which does start new threads), something is broken: The shared-object's init functions are run on the original thread, so they cannot access the TLS variables.
As a workaround, @benoit-canet proposed a patch where osv::application first sets up static TLS (which will effect only new threads), then creates the new thread, and then, in it, runs the initialization functions.

I think it should be possible to fix the underlying problem, i.e., to fix init_static_tls() to resize and rebuild the current thread's static TLS area - not just set up the one for new threads. If we would do that, we won't need to modify the application creation code to split the loading and initialization parts. Moreover, things would work even if we chose not to create a new thread at all. We also need to consider what happens when the library is unloaded (we may be unable to reduce the TLS area's size and need to leak memory?).

[nyh]

If we want to support initial-exec in a shared object loaded by program::get_library() - and not just a new app returned by osv::application::run(), we also need to note this:

thread::setup_tcb() sets up the initial-exec area for new threads. It needs a list of shared objects to include in the initial-exec TLS area for the new thread, and finds this list by looking at the current thread's app_runtime object and look at its initial_tls(). That was set up by object::init_static_tls() and only included objects loaded by dependencies, not get_library(). So get_library() needs to update _initial_tls of the object of the current thread's app_runtime (similar to init_static_tls()) and then use that to rebuild the tcb (similar to setup_tcb but without destroying already existing data). We probably also need to update _tls for accessing the same data through non-initial-exec tls methods. All of this is pretty complex to do properly...

@benoit-canet 's workaround of supporting initial-exec only for osv::application::run() by running the library's init functions only in the child thread is starting to look appealing... If we do this, we should at least find a way of warning when loading a shared object with initial-exec variables in an unsupported way....