Summary of the new feature / enhancement

As an infrastructure engineer, I want to be able to define version pins for the resoures in my configuration documents to ensure my configuration management is as deterministic as possible.

Proposed technical implementation details (optional)

A few options come to mind.

The easiest-for-users would be to allow them to append a version pin to the end of the resource type name for a resource, like Microsoft.DSC/PowerShell@v1.0.0. This would require introduce complexity to the engine for handling and impact the way configuration functions work, which makes it a harder sell to me.

The more explicit option is to support a version field on the resource instance declaration:

- type:    Microsoft.DSC/PowerShell
  version: v1.0.0

Another option would be to define it under resource metadata:

- type: Microsoft.DSC/PowerShell
  metadata:
    Microsoft.DSC:
      version: v1.0.0

Of the available options, I lean more towards the metadata implementation, even though it requires defining per-resource metadata. However, we've discussed other uses for this property bag, and defining a structure for this would pave the way for those use cases. It would also enable users to declare version pins in the top-level metadata with per-resource overrides (if we choose to support that).

I don't think this would require any further work for adapters, since they already report available resources and versions to DSC.