Collapse ensure and dsc_ensure attributes

[michaeltlombardi]

Use Case

When writing a manifest for a DSC Resource that is not ensurable, it would be preferable to not have any erroneous ensure keywords to confuse an author; similarly, if a resource is ensurable, it should have one attribute to set, not two; again, to limit confusion and keep a more idiomatic authoring experience.

Describe the Solution You Would Like

Unensurable resources do not have the ensure attribute at all; ensurable resources have the dsc_ensure keyword. This will require moving away from inheriting from the simple provider and instead being it's own provider entirely but will also retain in-place upgrades, not requiring the end-user to modify their manifests, only their puppetfile.

Acceptance Criteria

• Generated unensurable resource has neither the ensure nor dsc_ensure attributes, can be applied without errors
• Generated ensurable resource has the dsc_ensure attribute, can be created, updated, and destroyed without errors