Define model for handling configuration expressions for non-recursive DSC group and adapter resources

[michaeltlombardi]

Summary of the new feature / enhancement

As a user, I want to be able to use functionality like dependsOn for nested resource instances in adapter and group resources, regardless of whether those resources are recursively invoking dsc itself.

As a developer, I don't want to implement my group and adapter resources to duplicate logic and handling for configuration expressions, but to be able to rely on DSC resolving those expressions.

In #695, the implementation was updated so that DSC doesn't recursively parse and handle configuration expressions for nested instances in group or adapter resources.

Currently, the PowerShell adapters just ignore the dependsOn field for nested instances. They invoke the instances in their declared order.

DSC does resolve some of the expressions, like concat() and resourceId. Other expressions that require deferring, like reference(), don't work.

For implementations of adapter resources and group resources that don't recursively invoke dsc, these expressions require the developer to implement handling in their own code.

Proposed technical implementation details (optional)

Ideally, we could provide a model for handling these expressions on behalf of the resource, but I can't think of a non-complex way to do so.

Potentially, we could provide handling for these use cases in the eventual RDKs for each language and make that functionality a core component of the RDK spec.

Otherwise, I foresee folks either not being able to use (many) expressions for nested instances or implementing their own custom behavior that may or may not align to the engine semantics for non-nested instances.