Allow resource manifest to specify required security context per method

[denelon]

Summary of the new feature / enhancement

In Microsoft.Windows.Developer, the "Developer Mode" value can be "read", but not "set" without elevation.

Export would retrieve the value, but if the user went to run the "set" back, it would require elevation.

Proposed technical implementation details (optional)

No response

[SteveL-MSFT]

DSC should fail fast when it knows an operation can't be performed and provide a better error to the user than when they try and part way through it gets access denied

[michaeltlombardi]

I think this could be addressed by adding a requiredSecurityContext field to the operation definitions in the manifest, e.g.

{
  "get": {
    "executable": "foo",
    "args": ["config", "get"],
    "input": "stdin"
    // Non-specified context defaults to `current`
  },
  "set": {
    "executable": "foo",
    "args": ["config", "set"],
    "input": "stdin",
    "requiredSecurityContext": "elevated"
  }
}

Though I think that will require some addressing of the configuration-document-level option to require an elevated or restricted security context and for a document with mixed-requirement resource instances.

[SteveL-MSFT]

One consideration is that when used in a config, there should be pre-validation of the securityContext requirement before deployment starts

[SteveL-MSFT]

Deferring the static analysis and created separate issue #1423