Allow configuration parameters to be passed as command-line parameters

[SteveL-MSFT]

Summary of the new feature / enhancement

Allow parameters to dsc after -- to be interpreted as parameters to the configuration.

Proposed technical implementation details (optional)

Assume a configuration that looks like:

parameters:
  osFamily:
    type: string
    defaultValue: Windows
    allowedValues:
      - Windows
      - Linux
      - macOS
  name:
    type: string

Then we could allow config parameters to be passed as command-line parameters after --, so something like:

dsc config get -p ./foo.dsc.yaml -- --osFamily Windows --name test

One limitation to this experience is that JSON is case-sensitive, so the parameter names would have to be case-sensitive. We could allow for case-insensitive and do an exact match first and then case-insensitive match if it only matches one (it would be a bad practice to have multiple parameters that differ by case, although it would be allowed). However, parameter values are also case-sensitive, so we'd also need to perform a best match if there's an allowedValues.

[SteveL-MSFT]

One limitation of this approach is that the completer we generate for dsc itself won't know anything about configuration parameters since those are dynamic depending on the configuration file or content being used.

I don't know how often someone would be using this interactively in the console, so it might be better time spent on a GUI instead.

[michaeltlombardi]

I do think a TUI experience would be better for interactive usage than not being able to complete the parameters or arguments in the terminal - and that it can be deferred until we tackle a TUI. Arguably, it would be a good use case for an extension, adding a TUI that makes it easier to interactively use DSC and manipulate/inspect the results data before emitting the final JSON.