Previously, any per instance metadata supplied via the GCE builder
was ignored.

Test plan:

- make test
- Manual testing via:
-- Created a packer config that contained a GCE builder with custom
   metadata set.
-- Ran `packer build`.
-- Verified the instance had the correct metadata in the GCE console.

builder/parallels: Create VM without hdd and then add it later

builder/parallels: Rely on Cleanup functions to detach devices

This is needed to make 'cdrom0' device unavailable during the ISO installation process.
It is required for some guest OS types, such as FreeBSD and OmniOS.

CD/DVD drive with installation ISO should be exactly the 2nd device in the VM boot order.
This ensures that VM will boot from this ISO at the first boot time only.

For each ISO image the individual cdrom device will be added to the VM. During the cleanup these devices will be deleted.
It makes attach steps more clear - there is no doubt what is the name of the device.

Related to: [mitchellh/packer#1502]

Remove the redundant StepRemoveDevices and rely on the cleanup to be handled by:
* StepAttachParallelsTools.Cleanup
* StepAttachFloppy.Cleanup
* stepAttachISO.Cleanup

Update website to use latest middleman

builder/parallels: Ignore 'The fdd0 device does not exist'

Avoid the disk resize because it is unsupported for some guests (OS X)
http://kb.parallels.com/en/113653

builder/parallels: Bundle python version of prltype

Uses the Python API from Parallels Virtualization SDK to write
boot commands.

This eliminates a 3rd party requirement and makes it easier for people
not using homebrew to get started with packer.

A current floppy disk probably doesn't exist, so the build shouldn't
fail when we try to delete it.

builder/vmware-esx: Ignore localhost for VNC lookup and document VNC requirements [GH-1480]

  Adds logic to ESXi driver VNC Address function to ignore listen
  addresses that bind to localhost (127.0.0.1), this allows certain
  default ports to be available on ESXi for VNC connections

fixed vmware-vmx step order

Run two builds in parallel with go get

By default, go get determines parallelism based on the number of
cores available. Those show up as 32 in the Travis CI environment
but a virtual machine is limited both by the amount of cores it
has allocated and the amount of memory available to it. 32 parallel
build processes are likely to exhaust the memory resources, leading
to killed processes.

This change reduces the number of builds running concurrently to 2,
which should reduce the likelihood of memory exhaustion greatly.

The number could probably be dialed up a little bit, but this should
give a good default reflecting the environment's resources.

website: Add group_vars and host_vars to Ansible provisioner docs