Guards of execute resource doesn't inherit command options from its parent resource

* Replaces https://github.com/opscode/chef/pull/2105.
* Removes `path` attribute from `execute` resource which is never backed by any logic.
* Adds a new guard interpreter for execute resource that can inherit :cwd and :environment from the original resource. 

There is an open question of: 
```
# TODO: Do we want to also get :group, :user, :umask ?
```

/cc: @opscode/client-engineers 

I'd prefer to keep an error that ends the run. This error was added as part of the fix for #1943, where the user was doing this:

```
powershell_script "Powershell guard testing" do
  code "\"Script executed\" >> \"C:/chef/cache/guardtest.log\""
  not_if { "$True" }
  guard_interpreter :powershell_script
  convert_boolean_return true
end
```

If you're not a chef/ruby hero, it's not obvious that these two lines do completely different things, and therefore that the above example wouldn't work:

```
  not_if { "$True" }
```
and
```
  not_if "$True"
```

It's a big presumption on our part that if someone has a block and a guard_interpreter, that they really wanted to run the block run as ruby code and the guard_interpreter is cruft that they didn't mean to leave there. I don't think we can DWIM here, and need to raise an error so the user can fix the recipe so that it is written to do what they want it to do.

Further, in the above example, the user mistakenly thought the resource was working correctly because they believed that powershell was returning true, so the not_if conditional was preventing the resource from running, when actually the string was being evaluated as true in ruby. In this case, if we ignored the guard_interpreter, even with a warning, it could be a long time before the user realized that this resource would never run, regardless of what they put inside the double quotes.