Rename 'activations' to 'initializers'

'activations' makes more sense for on-demand activation.
compile-c: allow passing extra compilation flags, patchelf and strip
Simplify importing from nixpkgs
ipsec-wrapper: Pass secure-upstreams explicitly

Adding 'secure-upstreams' to the service interface for the ipsec-wrapper
is exactly the kind of "merge together definitions from an attribute in
a global namespace" thing that underlies one of the major difficulties
with the nixos module system. Any functions that add in some extra
default services which themselves have configuration options should
expose those through top-level function arguments instead.

Note that ipsec-wrapper.nix is approximately such a function, though due
to its nature as a bridge between the module system it exposes its
arguments modularly (which is to say, non-modularly).
Reduce the defnixos service interface

'services' should only expose the minimal information needed to
implement scheduling semantics, i.e. "what to run" and "when to run it".
Everything else that the service scheduler doesn't need to know about
should be encapsulated by "what to run".

Currently, the exposed information is:

* start: an executable to run to start the service
* initializers: a list of executables that are guaranteed to run to
  completion at least once before the first time the service is started,
  in no particular order. They should be idempotent, as they may run
  arbitrarily many times (and of course may be interrupted
  mid-execution). The intent is to set up initial state for the service.

Some future candidates for inclusion are:

* on-demand: On-demand services (using e.g. socket activation) require a
  somewhat involved ordering to avoid races. First each on-demand
  service should be started, then once each reaches a "listening" state
  non-on-demand services can be started and on-demand services can be
  told that they can actually start when ready. This needs to be
  orchestrated by a manager that knows about all services and whether
  they are on-demand (but only whether, not any specific details).
* handoff: A mechanism to allow one instance of a service to hand-off
  control to a new instance (to be used for 0-downtime type setups)

But any factors that affect the execution environment but don't need to
know about the other services should be encapsulated by the start
command.