In some contexts, the C compiler can integrate few -I and -L and pthread
becomes standalone from the user's point-of-view. However, in the context of
a C cross-compiler, standalone pthread's definitions can be different than the
host system (available into [default_search_paths]) and they can clash.

This patch allow us to compile a C code without any flags and let the
C (cross?)-compiler to solve by itself where is pthread. This behavior is added
from what src/unix/config/discover.exe did before.

This patch use if/else if/else instead of a switch ... case which
expects constants. These values are not constants from the Cosmopolitan
libc which set these variables at the "boot" of the application and set
them with the right value according to the running system.

Instead of a static & global array, we moved the array of MADV_* values into
the function which uses it.

Instead of a static & global array, we moved the array of TC* values into
the function which uses it.

Instead of a static & global array, we moved the array of WNOHANG & WUNTRACED
values into the function which uses it.

This patch create 2 C functions to initialize an array with speed values
or termios values. If we pass NULL to these functions, they returns the
length of the array. By this way, we initiate required arrays which
contains speeds & termios value at the runtime - instead of the compile
time.

This patch is needed because these values are not constants for the
Cosmopolitan libc and we must set/initialize arrays at runtime.

This patch is probably the more invasive about Esperanto/Cosmopolitan. It adds
a new compilation path when [__ESPERANTO__] is defined. A note was added to
explain where it comes from: the cross-compiler [arch-esperanto-none-static-cc]
systematically defines [-D__ESPERANTO__] in order to let third-party libraries
(such as lwt) to choose different compilation paths. And here we are!

Cosmopolitan does not defines required [_SC*] constants and
[unix_get_pw_gr_nam_id_job] can not be compiled. We discard this piece of code
when we want to compile with Cosmopolitan as it's the case for Android too.

The default case of [C_library_flags.detect] puts systematically
[-I/usr/include] and [-L/usr/lib] even in a cross-compilation context which is
wrong because [/usr/include/pthread.h] can clash [cross-env/pthread.h] for
instance.

The default case about underlying libraries (libev or pthread) should be
available only from a restrictive set of flags instead of a pervasive one. This
patch restricts this set to what we really need instead to pervasively picks
some random flags.

A clarification about the recognition of [pthread] was made too to really
understand the behavior of [discover.exe] and give a chance to be more
reproducible afterwards

If we consider pthread as the default implementation needed by lwt, we
should prioritize the recognition of [pthread] before [libev] but more
concretely, due to the undeterministic behavior of [discover.exe] and
our usage of [C_library_flags.set_{c,link}_flags] to reset any flags
when we can link [pthread] from a cross-compiler, it seems that we reset
aggregate flags needed for [libev] (specially [-lev]) in the same time.

This patch aggregate flags needed for [pthread] first and let the
recognition of [libev] then. However, that mostly means that in the
context of the cross-compilation, the user must NOT install
[conf-libev] (otherwise, we will try to link with the host's [libev]
which is obviously incompatible with our cross-compiler). This patch
wants to keep, as much as we can, the same behavior - but it highlights
limits of [discover.exe].

The last release of esperanto does not define speed_t constants. We must
protect the definition of our speed_t table when the toolchain is
esperanto.

Currently, the Cosmopolitan/Esperanto toolchain protects the usage of
pthread and we are not able to pass to it 0. This patch allows us to
compile (and recognize the support of pthread) the code with the
esperanto toolchain.