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
Add nginx service
Add function for deterministic calculation of ids

Also introduces an "eval-support" set, for things that need to run
derivations at evaluation time.
execve: Support for switching user
php-fpm: Just take the config and ini as arguments
Introduce run-as-user for user switching

By default we compile a wrapper that calls setuid before execing the
program, but the program can specialize running as another user.
multiplex-activations specializes it to run the *wrapped* program as the
new user (so that resources such as sockets are acquired as root) and
execve specializes it to call setuid in the same process.
php-fpm: Don't specify user, that can be overridden externally
Add packages to run a set of programs in parallel or sequentially
Only allow specifying a single initializer

seq and par can be used to combine them

Fixes #20
nginx: Just take a config file directly
Remove unused dirs initializer
Initializers are just pkgs, nothing special
When the target and eval-time system differ, usually 'system' is globally overridden
Missing word
run-as-user -> run-with-settings
Add a convencience service wrapper for running a service with execution settings
Argument renaming