Fix Powershell Dependency in DSC Module

From GitHub Issue #203
https://github.com/puppetlabs/puppetlabs-dsc/issues/203

Ben Charlton (bcc on Github)
—
It looks like this restriction on <2.0.0 has broken the ability to install the older 1.0.0 too, which means that you silently end up with the broken 0.8.1. Forcing the version to 1.0.1 means the dependency resolution hard fails. A workaround that seems to be working so far for me is to force install powershell 1.0.6 then install dsc.
—
Yep, sorry for the idleness.

My puppetmaster is built from scratch every time (in vagrant, other environments as required), just doing a build results in:

chocolatey/metadata.json:  "version": "1.2.6",

dsc/metadata.json:  "version": "0.8.1",

firewall/metadata.json:  "version": "1.8.1",

powershell/metadata.json:  "version": "2.0.2",

registry/metadata.json:  "version": "1.1.3",

sslcertificate/metadata.json:  "version":      "2.1.1",

stdlib/metadata.json:  "version": "4.12.0",

windows_env/metadata.json:  "version": "2.2.2",

If I clear out the module directory:

# puppet module install puppetlabs-dsc --version 1.0.0 --modulepath /etc/puppet/modules/

/etc/puppet/modules

 puppetlabs-dsc (v1.0.0)

   puppetlabs-powershell (v1.0.6)

   puppetlabs-reboot (v1.2.1)

   puppetlabs-stdlib (v4.12.0)

I can no longer reproduce the dependency resolution hard failure, so I'm not sure what was going on there.

By default I'm ending up with the latest puppetlabs-powershell first (as I have an explicit dependency on that module, separately to dsc), which results in dsc 0.8.1 being the latest version that will install. I can work around this by forcing dsc to install first, but it would really be nice if the dsc module didn't restrict powershell to < 2.0.0 as dsc 0.8.1 is quite badly broken if you're trying to do anything with IIS bindings.