DSC Feature Flags / Optional Units

Description of the new feature / enhancement

When writing a DSC file, there may be both common workflows (the ideal use case for DSC) as well as optional workflows that may be necessary for various development areas. Take winget-dsc as an example - users working on any DSC resource in that repository will need some standard set of tools, which are currently installed by the configuration.dsc.yaml.

If working on the NpmDsc resource, then Node.js should also be installed. However, not all contributors will be contributing to that resource and may not want Node.js installed if it is not necessary for their contributions. The same could be said about Python - users may already have a specific version installed and not want the latest, or may not want Python at all, if they are not working on that DSC resource.

It would be beneficial if there were a way to specify steps in a DSC yaml file as optional. Inspiration could be taken from Rust's features implementation, where the defaults can be set by the author of the resource, and consumers can use --no-default-features to disable all optional configuration units, and/or --features [<feature>] to enable specific optional modules if they are not specified as a default feature

Proposed technical implementation details

No response

Start by reviewing the configuration.dsc.yaml example in the issue and the proposed --no-default-features and --features options. Compare the desired optional-unit behavior with Rust features, then determine how defaults and selected DSC modules should be represented and verified.