Add a socket-activated php-fpm service.

This involved introducing a number of new concepts:

service runtime directory: Each service has its own ephemeral runtime
directory, to be used for communication between the service and the init
system and for communication between old and new versions of the
service. Note that it should *not* be used for inter-service
communication (directly or indirectly). Services are started with their
working directory in the runtime directory.

on-demand services: An on-demand service is expected to do some quick
work to setup on-demand activation, then signal readiness via the
NOTIFY_SOCKET mechanism (see sd_notify(3), though the interface is in
principle init agnostic), then wait for a datagram on 'notify.sock' in
the service runtime directory, then start the actual service when ready.
This dance is required to implement proper startup semantics for
on-demand services: First all on-demand services should get to a
"listening" state, and only after all of them are listening can any of
them (or any non-on-demand) service be allowed to actually run (in case
they talk to each other). Note that the content of the datagram recieved
on 'notify.sock' is currently not inspected, it may be desirable to
require a specific message instead in order to allow future protocols
over the socket.

compiled arguments: A way to create a 'configuration' file for
defnix-specific programs that requires no parsing, just mapping into
memory and using the contents directly. Rather than marshalling nix
values -> configuration file at deploy time and then configuration file
-> program values at run time, we just go from nix values -> program
values at deploy time. The compile-arguments build-support function
takes a name for the arguments file and a list of arguments, which can
currently be strings, ints, or booleans.

multiplexable activations: A list of multiplexable activations can be
passed to multiplex-activations to create an on-demand service that
starts when any one of the provided activations is ready. A
multiplexable activation is a compiled arguments file, where the first
two arguments are the path to a DSO and a symbol name, respectively,
such that the given symbol in the given DSO is a function taking an
epoll file descriptor and a void pointer. At run time, the function will
be called with an epoll fd and with the void pointer pointing to just
after the second argument in the arguments file (so you can pass
arbitrary extra arguments to your function). The function should do
whatever setup it needs to do and modify the epoll set to return an
event when the activation is satisfied. See
defnixos/activations/socket/default.nix for an example.
compile-arguments: Remove relic of writing to stdout
Remove relic of multiplex-activations living in the activations dir
multiplex-activations: dup epoll fd out of the way to avoid leaving a gap in low fds