DSC Resource manifest schema should allow for setting properties as "keys"

Summary of the new feature / enhancement

While we can use the schema to define the properties and their individual schemas, there is no way to specify that a particular property is a "key". This is distinct from required/optional. The set of all "key" property values given to a resource defines the identity of the data under management. Thus, passing the same set of key values, while varying other values, will result in a potential overwrite of the managed data.

The goal is to be able take two sets of properties that are intended for the same resource and determine if they are in conflict. As an example:

<config1 contains>
- name: A
  type: my/packages
  properties:
    id: foo
    version: [1.0-2.0)

<config2 contains>
- name: B
  type: my/packages
  properties:
    id: foo
    version: [3.0-]

With the resource my/packages having a property key set containing id, we can determine that config1:A and config2:B are potentially in conflict (they have matching key values and differing non-key values). This can be reported to the user so that they may determine how to proceed.

Proposed technical implementation details (optional)

No response

Start by locating the DSC resource manifest schema and the code that interprets resource properties. Define how a schema marks key properties and how matching key values identify conflicting configurations, then verify that the example configurations are reported as potentially conflicting while differing key values are not.