Signed-off-by: Pete Higgins <pete@peterhiggins.org>

All required properties are now required for all actions by default
even if the action does not reference the property.

In order to only make the property required for a subset of the
actions, specify them as an array of symbols to the required
options on the property.

```
property :whatever, String, required: %i{start stop}

action :start do
end

action :stop do
end

action :enable do
end

action :disable do
end
```

That property will be required for start+stop but not for
enable+disable.

There's an unaddressed edge case here where if you reference the
property in an action which was not specified that it will also
fail validation.  That is correct behavior.  We should probably
dig into how to warn the user that they must either remove the
reference to the property from that action or else to add the
action to the list of required actions on the property.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

For custom resources which correctly implement load_current_value the
new after_resource comes for "free" and load_current_value will be
called twice to load the current_resource (should be renamed the
"before_resource" but that ship sailed) and then the after_resource.

Appropriate wiring is added for a new event and capturing that into
the action_collection and then the data_collector.  The resource_reporter
has not and will not be updated.

For old style resources which are difficult to convert to custom
resources (thinking here particularly of the 1:N model of the service
resource in core chef, or stuff that just may be a lot of work like the
file resource) then they can override the load_after_resource to
manually wire up their own after_resource.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

This lets us avoid using declare_resource in old style core resources.

As everything gets converted over to custom resources this is going away
anyway.

We haven't seen any issues from using the recipe DSL in custom resources
in core.

Clearly this is potentially breaking since any references to
Chef::DSL::Core need to be changed to Chef::DSL::Recipe (although I'm
not sure who would have done that other than maybe us somewhere, I had
a note in there that nobody should probably touch the Core DSL).

This greatly simplifies the major DSLs down to two:

Recipe DSL - things that only make sense in a context where there is a resource_collection
Universal DSL - things that apply everywhere

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

This is the implementation of [RFC-087](https://github.com/chef-boneyard/chef-rfc/blob/master/rfc087-distro-sugar-helpers.md)
although some of the specifics have been iterated on and changed.

The documentation will be in the [README.md](https://github.com/chef/chef/tree/master/chef-utils/README.md) once this is merged.

While this PR mostly moves chef-sugar utilities into core-chef via this chef-utils gem, the scope of the chef-utils gem
should be considered larger than just that. As an example this PR moves the Mash class into this gem for reuse in ohai
as well.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>

Fixes #6300.

This may be a breaking change.

Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>