Update the NuGet package generation to include 'cimcmdlet.dll' and most of the built-in modules

[daxian-dbw]

PR Summary

Fix #11783

• Generate and include Microsoft.Management.Infrastructure.CimCmdlets NuGet package
• Include all built-in module folders in Microsoft.PowerShell.SDK NuGet package except for the PSDesiredConfiguration module.
  • PSDesiredConfiguration module is not included because it has files in nested folders, which cause the file path length to be more than 180 in the dotnet-interactive global tool, so it will require the long path support to work. I'm not sure if this would be a problem, and thus don't have it included.

PR Context

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
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • 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).

[daxian-dbw]

The solution is not perfect.

This fix targets dotnet publish because that's what we use for both the Azure Function worker and dotnet-interactive global tool.
Most hosting application probably can be covered by this usage to generate a self-contained package that is portable to all platforms.
It turns out dotnet build also generates the runtime folder in the build output folder, so it works fine for dotnet build.

For dotnet publish -runtime <rid>, this could be used by a hosting application in case the dotnet runtime is not installed on the target platform, but since the content files will be bin-placed to the output folder, the hosting application author can always write a simple post build script to correct the path and make it work. So I think we are fine there.

[adityapatwardhan]

@daxian-dbw If a doc issue was filed, please add the link in the description

[ghost]

🎉v7.0.0-rc.3 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes