Support for pre-configuring communicator transports (SSH or WinRM) via init_script setting

This adds support for an `init_script` setting. The `init_script` is a small script that run before the Vagrant communicator connects to run Vagrant provisioners. The use of `init_script` should be avoided whenever possible, since a normal provisioner is more portable and easier to troubleshoot when something goes wrong (since Vagrant will capture the results), but the use of an `init_script` is sometimes needed to configure the communication protocols for communication with Vagrant.

Two known cases that require an `init_script` (in order to work with Rackspace base images rather than having to create custom images):
- Disabling sudo requires tty for the RHEL family of Linux distros (RHEL, Fedora, Centos). If it's not enabled it causes problems with rsync (https://github.com/mitchellh/vagrant-rackspace/issues/115).
- Enabling and securing WinRM on Windows machines. WinRM is the "Windows equivalent of SSH" (although it doesn't tunneled protocols for file transfer) but is not enabled on base images.

The intention of `init_script` is the same for SSH & WinRM - it after the server is booted but before we tell Vagrant the machine is ready to provision. However, the implementation is slightly different for the two:
- If the transport is WinRM, then we send the script via server personalities to "C:\cloud-automation\bootstrap.cmd", is run when the server starts. This is necessary because we usually can't connect to WinRM at all by default. It does mean we can't capture the output or see if the script failed.
- If the transport is SSH, then we connect and run the script via SSH. So the script can include customizations that will apply to future SSH connections (including protocols tunneled over SSH, like rsync), but assumes that a basic connection is working. The output can be captured.

It might be possible to run the init_script for SSH via cloud-init, so it would be more consistent with how `init_script` works for Windows, but that's more complicated, harder to troubleshoot, and I'm not sure cloud-init is supported on all images. So I'm not sure its worth it until there's a known use-case.
:point_up: I'd say, keep it as letting the API validate the script length. That way we're insulated from configuration or account changes that would alter the limits. There would be nothing more annoying than having your account adjusted to allow a larger init script, but have Vagrant shut you down before it even tries the call.