Cross-platform updates to DSC code in SMA DLL

[anmenaga]

PR Summary

This PR is in context of DSC changes for PowerShell 7.
P0 end-to-end scenario that we are enabling here consists of 3 components: PowerShell core (SMA dll), PSDesiredStateConfiguration module, GuestConfigAgent.
This PR addresses the first part - updates to DSC code in SMA dll to remove dependency on MOF/MMI APIs, therefore making DSC cross-platform and enabling GuestConfigAgent scenarios.
Focus is on class-based DSC resources.

PR Context

Fix #13731

At this point this PR is not a breaking change: existing (MOF/MMI-based) DSC code will continue to work as it was and will continue to be the default mechanism for DSC operations (for now).
Cross-platform DSC updates of this PR are done as an alternative mechanism for DSC operations; to use them:

1. PSDesiredStateConfiguration v3 module has to be installed;
2. PS7DscSupport experimental feature has to be enabled.

Example:

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Support only DSC class based resources
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed: Update docs related to DscClassCache and MOF->JSON transition for DSC resources MicrosoftDocs/PowerShell-Docs#6470
• Testing - New and feature
  • N/A or can only be tested interactively:
    • new code requires DSC v3 module which is not published yet;
    • DSC code in SMA is essentially a set of utility functions (expected to be moved to DSC module repo); proper test automation belongs to DSC module repo;
    • existing test automation in this repo ensures no regressions in MOF/MMI-based implementation.
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[iSazonov]

Are there performance comparisons? It would be very amazing if new schema worked slower than original.

[ThomasNieto]

The cmdlet name to convert MOF to JSON doesn't fit the naming conversions. It looks only to be one directional not bi-directional. Convert-CimMofToJson to something like ConvertTo-DscJsonSchema. The PS verb description for Convert indicates bi-directional and ConvertTo is one directional.

Convert - Changes the data from one representation to another when the cmdlet supports bidirectional conversion or when the cmdlet supports conversion between multiple data types.
ConvertTo - Converts from one or more types of input to a primary output type (the cmdlet noun indicates the output type).

OOF

[TravisEz13]

Reviewed the changes to build.psm1 and the changes to find PSDesiredStateConfiguration.

[daxian-dbw]

LGTM

[daxian-dbw]

@rjmholt Can you please update your review? Thanks

[iSazonov]

@anmenaga Great work!