This required to make the polkit-related steps more generic: there's more
than one possible polkit prompt.

The Sikuli images are now updated for Wheezy.

Sometimes Sikuli fails to find the shutdown icon in the shutdown
applet's menu (possibly because it's covered by a notification) so
that method isn't completely reliable at the moment. To contain this
problem we test the shutdown applet separately, and rely on the more
dependable remote shell for halting in the general case.

While we're at it we also make sure that the shutdown steps are
formulated so what they do is more explicit.

In commit 13dce7f it was changed from the title to the task icon, and
since we wait_and_click it, that causes a minimize + maximize that may
result in key presses getting lost.

While we're at it we also rename it to *Window.png, to be consistent
with how we have named the other similar images, and to hopefully
prevent a similar bad update in the future.

This feature may otherwise fail randomly given how we currently delay
the start of Vidalia.

In Wheezy's GNOME all notifications disappear quickly, so we don't
have to actively close them, which has proven to be a bit error prone.

One call of detected_ram_in_bytes was forgotten.

In Wheezy notifications are automatically hidden farily quickly, which
makes all such attempts error prone.

This requires that setting the sudo password is the first thing we do
after opening the Greeter's options screen.

This reverts commit 5b20303d,
which is useless now that 31b8743 was essentially reverted.

We merge "Tor has built a circuit", "the time has synced" and "Tor is ready"
into a single step called "Tor is ready". This simplifies scenarios quite a bit,
and allows us to always do the checks in the right order, without each scenario
trying its own version.

Speaking of the right order: we wait for the "Tor is ready" notification first.
it disappears after a timeout, so if we wait for other events first, we
sometimes cannot find the notification picture on screen later on.

Previously we captured all traffic originating from the Tails VM's MAC
address, obtained from the static configuration. However, with the
introduction of MAC spoofing, the static configuration won't match
what's actually used. Instead we simply capture all traffic that
doesn't originate from the bridge.

Due to the MAC spoofing feature we also remove the `mac` attribute
from the VM class to not cause future confusion.

In the winxp feature, the "clicking on the start button" approach
leaves the cursor on the start button, blocking its view so that it
breaks the "The panel menu should look like Microsoft Windows XP's
start menu" scenario.

In case the applications ("start") menu is open, ALT-F2 does not work.
Let's close the menu first.

Else, if the system is fast enough, the next notification immediately moves to
the exact place where the one we just closed was, and the mouse cursor (still at
the same place) highlights the cross button (even if we hide it with
hide_cursor), which prevents Sikuli from finding it and close the
next notification.

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.

I have seen some weird race condition cases where the GNOME Run dialog has the
command to run ("gnome-terminal" in my case) correctly typed in, the text cursor
at the end, and the command step was not run, so the step fails with
"FindFailed: can not find GnomeTerminalWindow.png on the screen."

Issue with completion? Too slow or too fast test system? Bug somewhere in the
Sikuli / Ruby stack? Anyway, let's just add guards against this case and be done
with it.

We'll reuse it elsewhere soon, to ensure the dialog has vanished after we
clicked Enter.

That is, according to the Art of writing step definitions in the
automated test suite docs.

The `I safely shutdown Tails` and `I shutdown Tails` were both
confusing names considering what they do. Merging the former into the
step when we wait for the memory wipe to finish, and renaming the
latter to say "completley" as in "we also wait until the computer
shuts down completely" hopefully make this clearer.

This it to account for that more RAM takes longer to wipe, which is
especially slow in a nested VM setup.

This reverts commit e384675d.

This simplification makes it so that the step in question always has
to be run as the first step of the type that sets some Tails Greeter
option, which is pretty confusing.