First pass at a working windows chef-solo provisioner

This provisioner has the proper defaults to work with a Windows guest. The existing provisioners can work with Windows, but they require too much non-obvious configuration for most people. A minimal config looks like:

```
    {
      "type": "windows-chef-solo",
      "user": "Administrator",
      "password": "mysecret",
      "cookbook_paths": ["../../cookbooks"],
      "run_list": ["windows", "windows::reboot_handler", "dotnetframework"]
    },
```

Unlike the *nix provisioner, this runs all the Chef commands through a scheduled task (hence the user and password). This is done for two reasons:

1. The SSH environment does not behave the same as a standard Windows logon. Non-trivial software installs fail when run through an SSH session.
2. If and when Packer supports WinRM, there are limitations in the ability to access network resources and truly run with the required Administrator privileges (for example SQL Server).

As is, I can standup non-trivial Windows boxes with Packer and Chef now.

I'm sending this to start a discussion more than anything else. This is missing tests and there is a ton of duplication between this provisioner and the existing chef-solo provisioner and even the PR for the chef-client provisioner.

Does it makes sense to have Windows specific provisioners? Instead, should the existing provisioners branch their logic depending upon the target guest OS?