DSC: dsc_script resource

@btm, @jdmundrawala, here's a version of the DSC stuff re-imagined as `dsc_script`. It currently inherits from `Script`, though I'm starting to think a compromise here is to just make it `Script`-like, rather than to inherit, as some attributes, e.g. `creates`, are somewhat meaningless (the resource is essentially idempotent without the need for `creates` or even guards). Also, while it might be cool in some ways, I don't actually want it to be used as a guard, and that's possible if it inherits from `Script`.

I think the following attributes from `Script` are useful for a `dsc_script` that isn't actually a `Script`:

* `flags` -- these are the flags you'd pass to a script file containing a `Configuration` keyword in PowerShell. The only supported flags currently are `ConfigurationData`, `InstanceName`, and `Outputpath`. I don't have a use case for `InstanceName` and we won't let them specify `OutputPath` since we control that, but `ConfigurationData` is definitely useful. We could also just make `ConfigurationData` an attribute, but we could wait and see and add it later. Also, I want to stipulate that a `Hash` must be passed for flags, another difference from `Script`. Curious as to what you think of that.
* `cwd` -- it's possible the script is sensitive to some directory location (we can't constrain what they express in PowerShell).
* `environment` -- again, they may use these somehow in their scripts. It's actually one way we could get around some issues expressing content for things like credentials.
* `timeout` -- not sure if we should allow for this, but I can see users wanting control over it.
I do think the messages that originate from LCM should be considered more reliable, and if we can parse them like you say, that might do it. From a reporting standpoint, all the non-"LCM" lines could be considered diff / whyrun.