…lter

In <containers#101>, specifically
commit cde7fab we started dropping
all capabilities, even if the caller was privileged.

This broke rpm-ostree, which runs RPM scripts using bwrap, and some
of those scripts depend on capabilities (mostly `CAP_DAC_OVERRIDE`).

Fix this by retaining capabilities by default if the caller's uid is zero.

I considered having the logic be to simply retain any capabilities the invoking
process has (imagine filecaps binaries like `ping` or
`/usr/bin/gnome-keyring-daemon` using bwrap) but we currently explicitly abort
in that scenario to catch broken packages which used file capabilites for bwrap
itself (we switched to suid). For now this works, and if down the line there's a
real-world use case for capability-bearing non-zero-uid processes to invoke
bwrap *and* retain those privileges, we can revisit.

Another twist here is that we need to do some gymnastics to first avoid calling
`capset()` if we don't need to, as that can fail due to systemd installing a
seccomp filter that denies it (for dubious reasons).  Then we also need to ignore
`EPERM` when dropping caps in the init process.  (I considered unilaterally
handling `EPERM`, but it seems nicer to avoid calling `capset()` unless we need to)

Closes: containers#197