Force-terminate VirtualBox and Parallels VMs so snapshot restore works properly

What does this MR do?

Forcibly terminates the target VM, even if the guest OS is uncooperative. The implementation of Kill is changed to forcibly (and synchronously) stop the target VM. Stop is no longer required.

Should resolve #1356 (closed) and #1279 (closed).

Why was this MR needed?

Version 1.5.3 fails to delete the created VM if the guest OS ignores the ACPI power button signal (VBoxManage controlvm <vm> acpipowerbutton). For example, OS X 10.11 only pops up a dialog to shut down / restart. VBoxManage (VirtualBox 5.1.4) will not delete a running VM, and fails with the following error:

VBoxManage: error: Cannot unregister the machine 'testvm' while it is locked
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "Unregister(CleanupMode_DetachAllReturnHardDisksOnly, ComSafeArrayAsOutParam(aMedia))" at line 155 of file VBoxManageMisc.cpp

As of 1.5.3, the virtualbox executor has two different ways of killing a VM: vbox.Stop and vbox.Kill. Currently Kill sends the power button signal while Stop forcibly stops via VBoxManage controlvm <vm> poweroff. (These meanings are backwards, which the MR resolves by removing Stop and changing the behavior of Kill.) However, there is actually no reason to perform a graceful shutdown under any circumstances. Consider the two modes of operation:

• Snapshots disabled (disable_snapshots = true)
  1. Executor clones new target VM from base VM (optionally from a live or cold snapshot)
  2. Build runs
  3. Executor deletes target VM (must not be running)
• Snapshots enabled (disable_snapshots = false)
  1. If target VM does not already exist and have a snapshot:
     1. Executor clones new target VM from base VM
     2. Wait until SSH comes up
     3. Live snapshot of target VM taken
  2. Restore target VM from previously created live snapshot
     • (If restore fails because target VM is already running, destroy it and start over)
  3. Build runs
  4. Shut down target VM in preparation for next build

In either case, there is no situation in which the target VM is not either freshly cloned or restored from a live snapshot. So performing a graceful shutdown is pointless.

The same issue applies to the Parallels executor, which uses an identical workflow to the VirtualBox executor.

Are there points in the code the reviewer needs to double check?

None.

Does this MR meet the acceptance criteria?

• CHANGELOG entry added (I assume this will happen in next release)
• Documentation created/updated (N/A)
• Tests
  • Added for this feature/bug (N/A)
  • All builds are passing
• Branch has no merge conflicts with master (if you do - rebase it please)