Initial implementation of Microsoft.WinGet.Configuration cmdlets.

[msftrubengu]

This PR adds 5 cmdlets

• Get-WinGetConfiguration: creates a configuration set given a file path.
• Get-WinGetConfigurationDetails: gets the details from a set.
• Invoke-WinGetConfiguration: applies the configuration and waits for completion.
• Start-WinGetConfiguration: starts applying the configuration asynchronously. Returns PSConfigurationTask.
• Complete-WinGetConfiguration: waits for the PSConfigurationTask to be completed.

For now, a call the Get-WinGetConfiguration is required to start. It returns a PSConfigurationSet which can be pass to the other cmdlets.

If Invoke-WinGetConfiguration or Start-WinGetConfiguration get called before Get-WinGetConfigurationDetails, they will retrieve the details.

There is no output in PowerShell except for debug messages and the objects. Future PRs will provide a better user experience similar to what winget configure does.

By default, Start-WinGetConfiguration won't write anything to the stream buffers (except the returned object).because it needs to be executed in the main thread. When Complete-WinGetConfiguration gets called, writting to the streams gets enabled. For now, all the messages before Complete gets lost but in the future, we can store them and show them (similar to what Start-Job/Receive-Job does).

This PR also adds a new ConfigurationProcessorPolicy enum for creating a ConfigurationSetProcessor and can be added via IConfigurationProcessorFactoryProperties. The enum is a mirror of the PowerShell Execution Policies. By default, winget uses Unrestricted (we should change in the near future) and the module uses the same as the current PowerShell session.

I couldn't get the execution policy at the time of creating the set processor because it is not possible to create a runspace based on the current session. At that point, we are already running in another thread so the runspace can't be found. This means that the two types of runspaces are always "hosted" which just means that there's a new runspace created from them.

When we enable variables in configuration, there needs to be something that makes them visible from the current PowerShell session to our runspace (maybe using synchronized hashtable).

Microsoft Reviewers: Open in CodeFlow