In UEFI mode, I see that the GRUB background image is left on the screen while
GRUB is loading the kernel and initramfs. That's nice for users, but it creates
a new failure mode: boot_menu_image can be found at that time, i.e. too late for
us to interact with the GRUB menu.

So in the "Booting Tails from a USB drive in UEFI mode" scenario, I've seen
cases on Jenkins when boot_menu_image is found and we happily proceed with
pressing "e" and 3 × "Down", but that input is lost, so the scenario fails when
looking for boot_menu_cmdline_image. We had no safeguard in place for this race
condition so far. Let's detect the symptoms of this problem and retry.

To simplify the implementation of this workaround, let's now manage the "up
spammer" process as a transient systemd unit, otherwise with the above change it
gets hard to do that: depending on the failure mode, when we reach the "ensure"
block, the up spammer can be running or not, and if not this cleanup step can
fail with IOError. I don't want to get into the messy business of rescuing
exceptions raised by an "ensure" block. systemd provides exactly the semantics
we need here, in a simpler way than dealing with Ruby IO objects.