Unfortunately, the virtual memory, resident memory, and network stats will
require access to undocumented C functions.  I was warned off of cgo in IRC
because it would then have to be enabled in a bunch of different projects that
use this module, but I already was against it because that would break the
ability to cross-compile.  There is no interface to `dlopen` built into golang.
The `github.com/ebitengine/purego` module looks promising (I can cross-compile
and call these methods), but I'm currently getting unexpected results.  I'll
follow up with that separately if I can get it working, but hopefully this stuff
is pretty uncontroversial.

Tested on macOS 10.14.6 (amd64), macOS 14.6.1 (amd64), and macOS 15.0 (arm64)
by spawning `/usr/bin/ulimit -a -S` and `/usr/sbin/lsof -c $my_process` from
the test exporter process, and `ps -o lstart,vsize,rss,utime,stime,command` from
the shell, and comparing results with the exported metrics.

I can't find documentation for `RLIMIT_AS` on macOS (specifically if it's in
bytes or pages).  It's currently being reported back as `RLIM_INFINITY`, which
seems reasonable, because I've come across reports that the value is ignored
anyway[1].  The bash 3.2 code for the built-in `ulimit` divides the value
reported by `getrusage(2)` by 1024 when printing, as it does for `RLIMIT_DATA`,
which is documented as being bytes in `getrusage(2)`.  The help for `ulimit`
indicates it prints both in kbytes, so it's reasonable to assume this is already
in bytes.

[1] https://issues.chromium.org/issues/40581251#comment3

Signed-off-by: Matt Harbison <mharbison72@gmail.com>

Co-authored-by: Ben Kochie <superq@gmail.com>
Signed-off-by: Matt Harbison <57785103+mharbison72@users.noreply.github.com>