DSC should pass the `name` field to resource invocations as metadata

[michaeltlombardi]

Summary of the new feature / enhancement

As a DSC resource author, I want to be able to provide trace messages with as much usable context to consumers as possible, including the specific resource instance that is being invoked.

Currently, resources don't have access to the name field from a resource instance in a configuration document, so readers of the resource trace messages may not understand which resource instance emitted those messages.

Proposed technical implementation details (optional)

Standardize passing the name field to DSC resources when using dsc config commands as part of the _metadata struct.

Resource authors would have to implement their resources to include the instance name if passed through metadata. For direct invocations with dsc resource commands, the resources shouldn't expect to receive a name for the instance.

[Bpoe]

With Azure focused scenarios in mind, I would like for resources to receive the entire payload, not just the properties section. It may also be necessary for resources to return the entire payload, not just the properties section. This would allow DSC resources to work more like Azure Resource Providers.

[michaeltlombardi]

I'm not sure I can see uses for passing the resource additional information outside of metadata/properties - the resource (based on current implementation/design) knows what resource type it is, and resources don't have a coherent way to deal with dependencies external to themselves.

For the return information I think rather than have the resource's get and just pass back this information, it would make more sense to have a flag on the dsc config commands to insert the data you're looking for (or handle that in the higher order tool).