deps can be null if a library has no dependencies (such as libc itself)

basically we temporarily make the library and all its dependencies
part of the global namespace but only for the duration of performing
relocations, then return them to their former state.

some of the code is not yet used, and is in preparation for dlopen
which needs to be able to handle failure loading libraries without
terminating the program.

1. search was wrongly beginning with lib itself rather than dso head
2. inconsistent resolution of function pointers for functions in plt

previously, a potentially-indeterminate value from we_offs was being
used, resulting in wrong we_wordc and subsequent crashes in the
caller.

why did gcc allow this invalid assignment to compile in the first place?

first, use $LD_LIBRARY_PATH unless suid. if that fails, read path from
/etc/ld-musl-$ARCH.path and fallback to a builtin default.

eventually (once dlopen exists) this behavior will be conditional on
dlopen/dlsym not being reachable.

the linker script caused a bogus DT_NEEDED entry

the use of this test will be much stricter than glibc and other
typical implementations; the environment will not be honored
whatsoever unless the program is confirmed non-suid/sgid by the aux
vector the kernel passed in. no fallback to slow syscall-based
checking is used if the kernel fails to provide the information; we
simply assume the worst (suid) in this case and refuse to honor
environment.

leaving it uninitialized caused unpredictable crashes or worse due to
calling an indeterminate function pointer.

some notes:
- library search path is hard coded
- x86_64 code is untested and may not work
- dlopen/dlsym is not yet implemented
- relocations in read-only memory won't work

this seems to be necessary to make the linker accept the functions in
a shared library (perhaps to generate PLT entries?)

strictly speaking libc-internal asm should not need it. i might clean
that up later.

if thread id was reused by the kernel between the time pthread_kill
read it from the userspace pthread_t object and the time of the tgkill
syscall, a signal could be sent to the wrong thread. the tgkill
syscall was supposed to prevent this race (versus the old tkill
syscall) but it can't; it can only help in the case where the tid is
reused in a different process, but not when the tid is reused in the
same process.

the only solution i can see is an extra lock to prevent threads from
exiting while another thread is trying to pthread_kill them. it should
be very very cheap in the non-contended case.

previously a long-running dtor could cause pthread_detach to block.