switch to being a systemd service #2

Right now we have a lot of simplicity by not running under systemd. But there are a lot of advantages to doing so; see e.g. https://github.com/coreos/bootupd#questions-and-answers

All of the below applies to us too:

• Why is bootupd a daemon?

It's not, really. The name was intended to be "bootloader-upDater"
not "bootloader-updater-Daemon"; the choice of a "d" suffix is
in retrospect probably too confusing.

At a technical level, yes there is a socket-activated systemd service
which will spawn a bootupd.service. However - the service will
very quickly auto exit. There's nothing long-running, so it's
not really a daemon.

The rationale behind this design is:

• Using a systemd service provides a robust natural "locking"
  mechanism.
• Using a systemd service ensures that critical logging metadata
  always consistently ends up in the systemd journal, not e.g.
  a transient client SSH connection.
• systemd services can easily have sandboxing applied, and
  while bootupd is obviously privileged we can still make use
  of some of this.
• Ultimately, we do probably want a non-CLI API (whether that's
  DBus or Cap'n Proto or varlink or something else). Having
  a socket (without a defined stable API) is preparatory work for that.