The internals in the library within readproc had an "interesting" way
of using the path variable. Sometimes global, sometimes from proctab
and sometimes local to the function, or passed through from one other
way.

Besides the issue of the path variable scope, using standard open()
means we cannot be sure that /proc/12345/stat and /proc/12345/cmdline
are from the same process, because the first may have died and we are
in a PID reuse situation. By opening the /proc/<PID> directory and
consistently using this, we remove the ambiguity. There are some
vague promises that open()ing /proc/<PID> turns it into a pidfd,
like pidfd_open(2) with all the guarantees that provides, but I'm
not convinced.

Why not use pidfd_open(2) then? Because what it returns a file
descriptor of type... nothing (st_mode=0). Some functions are fine
using the fd, but openat() fails. statx() works if the pathname is
null, but not if it has a value. A lot of functions expect the
fd to be a type directory, and pidfd_open isn't (quite) that.

Trying to use openat() with a mode O_PATH for directories gives
a different set of problems. While subsequent openat()s on
subdirectories work, fstat() fails; hence the strictly not-required
O_RDONLY mode is used instead.

After multiple runs with strace, the only direct opens are for
the directories /proc, /proc/self and /proc/<PID> however there
is a possibility there is a code path that doesn't reset/establish
the dirfds correctly.

Signed-off-by: Craig Small <csmall@dropbear.xyz>