Improve handling for non-enforceable resources in `dsc config set`

Summary of the new feature / enhancement

As a user, I want to define a configuration that includes a non-enforceable resources in my configuration document without needing to edit the document prior to calling dsc config set.

Currently, if a configuration document includes a non-enforceable resource outside of a DSC/AssertionGroup instance, the command raises an error during configuration validation. However, a configuration document that defines non-enforceable resources outside of an assertion group are valid for both get and test operations.

Users should be able to indicate at the resource level or command level that non-enforceable resources should be ignored for the set operation. If a confirmation model is adopted, DSC should offer users the choice to abort or continue the operation when the command is run interactively and the user didn't indicate how to handle non-enforceable resources explicitly.

This doesn't obviate the need for the DSC/AssertionGroup, which ensures that enforceable resources don't change system state during a set call.

A further consideration is whether non-enforceable resources should still be tested during a set operation. I think that it makes sense for DSC to test those resources and allow them to be referenced as dependencies for other instances.

Proposed technical implementation details (optional)

No response

Start by reading the implementation and validation path for dsc config set, then compare how get and test handle non-enforceable resources. Done means the behavior and user choice for non-enforceable resources during set are defined and covered for resource-level and command-level handling.