service: warn when capabilities cannot take effect

An ambient capability only reaches the effective set when euid is
non-zero, so a service that pairs `capabilities = { "^cap_..." }` with a
root user gets none of the restriction it asks for, and keeps the full
root set instead.  Finit read the list, applied it, and said nothing.  A
build without libcap dropped the list on the floor just as quietly.

Both now warn, naming the service:

    nginx: ambient capabilities ('^') have no effect as root, use a
    non-root user, or '%' and '!' entries

The ambient entries are read back from the parsed IAB value rather than
matched in the text, so inheritable ('%') and bounding ('!') entries stay
silent -- those work fine as root.

The warning repeats when the .conf files are re-read on runlevel change,
as parse warnings here already do.

Signed-off-by: Joachim Wiberg <troglobit@gmail.com>

doc/config/capabilities.md

@@ -169,7 +169,8 @@ ps -o user,pid,cmd -p $(pidof nginx)
 
 - Linux kernel 4.3+ (for ambient capabilities support)
 - libcap library installed
-- Finit built with `--enable-libcap`
+- Finit built with `--enable-libcap`, otherwise a `capabilities` list is
+  ignored, with a warning
 
 ## Limitations
 
@@ -181,6 +182,10 @@ ps -o user,pid,cmd -p $(pidof nginx)
   - Using `user = "root"` with `^` capabilities will not work effectively, as ambient
     capabilities are only added to the effective set when euid ≠ 0
   - Use inheritable (`%`) or bounding (`!`) capabilities with `user = "root"` if needed
+  - Finit warns about this when reading the .conf file:
+
+        nginx: ambient capabilities ('^') have no effect as root, use a
+        non-root user, or '%' and '!' entries
 - Services without `capabilities` use standard privilege dropping:
   - Services with a non-root `user` have no special capabilities
   - Services without `user` run as root with full capabilities