Rename scenarios to make room for the corresponding anti-tests.
First try at an anti-test for memory erasure.
Allow pidof to detect scripts too.
Add a pidof utility function.
Always use the pidof instead of pgrep.

As previously noted, pgrep sometimes detects itself, which breaks the detection
that all fillram instances have vanished.
Use spawn instead of execute to trigger a reboot over sysrq.

This command won't ever return anything to us, so it's useless (and broken) to
wait for the remote shell to reply anything to us.
Don't pretend we have filled all RAM.

We display something more precise (and generally < 100%) soon after, so it makes
no sense displaying "Memory fill progress: 100%".
Add a VM.reset utility method.

... using virsh as ruby-libvirt 0.4 does not support the reset method :(
Force reboot the VM with libvirt instead of using sysrq.

This should be more robust.
Wait for a dedicated boot splash screenshot at post-VM-reset time.

At this time, the display resolution is different from the one on startup,
so Sikuli can't find TailsBootSplash.png.
Add memory erasure anti-test for non-PAE too.
Optimization: don't dump guest memory twice in the anti-test.

We already grep for the pattern after rebooting, no need to do it
before.
Explicitly tell virsh which libvirt URI it needs to connect to.

Else, when the test suite is not run as root, virsh connects to the *user*
libvirt instance by default, instead of the system one, and as a result it
cannot even see the TailsToaster domain running, as noticed by anonym:
https://labs.riseup.net/code/issues/5959#note-9
Allow a 196 MB gap with the amd64 kernel: that one eats more memory.
Allow finding a bit more patterns after wiping memory.
Move MAC spoofing documentation to Startup Options
Rework the MAC spoofing documentation
Do not repeatedly press Enter until the GNOME Run dialog vanishes.

The repeated pressing was introduced earlier (in commit c80ae9e) to
workaround a possible GTK bug (or similar). However, if sikuli is
faster than GNOME, sikuli may `find` the GNOME Run dialog even after
pressing Enter, hence pressing Enter more than once. The extra Enter:s
may propagate to whatever application that was started by the run
dialog, which in the case of the Unsafe Browser, for instance, will
close its verification window.

To workaround the original issue we instead simply sleep for a short
time inbetween typing the command and pressing Enter.
Fix typo.
This was fixed already.