Move internal globals to TLS to protect mutual access on FLAT mode

As per recent discussion, some APIs such as getopt() use global variables internally. This means getopt() calls between different tasks (or even calls done in subsequent runs of the task) will see changes of these globals. The idea is to move these variables to TLS and provide safety at the thread level.

Note that even when reentrant versions of a function exist, code expecting a non-reentrant function to work will still break due to this interference so it is not a solution to just switch to a reentrant version of a non-reentrant POSIX interface.

The list of functions potentially requiring adaption is as follows:

- [x] libs/libc/misc/lib_umask.c has g_mask
- [ ] libs/libc/libgen/lib_dirname.c and libs/libc/libgen/lib_basename each
have a g_retchar
- [ ] libs/libc/syslog/lib_setlogmask.c has g_syslog_mask (and a comment
describing this issue)
- [ ] libs/libc/pwd/* uses either g_passwd and g_passwd_buffer or g_pwd and
g_buf
- [ ] libs/libc/grp/* uses a similar pair for group data
- [x] libs/libc/unistd/lib_getopt.c we know of, it has four words of global
data
- [ ] libs/libc/time/lib_localtime.c uses g_tm and may need per-task timezone
settings
- [ ] libs/libc/netdb/lib_netdb.c specifies h_errno as a global
- [ ] libs/libc/netdb/lib_gethostbyname2.c and lib_gethostbyaddr.c use
g_hostent and g_hostbuffer
- [ ] libs/libc/stdlib/lib_srand.c uses a variety of globals depending on
build options
- [ ] libs/libc/string/lib_strtok.c uses g_saveptr