Add a Generic Package Resource & Registry

Summary of the new feature / enhancement

As a xplat user I want to build small modular configurations that work across all platforms

To do this a generic package resource is required.

As is a Package Registry that we can lookup that can contain additonal package information like GitHub/GitLab Repository etc.

Note this is not a small undertaking beacuse of the need to manage the Package Registry, but shouldn't take too long to design, build & then deploy a Proof of Concept that also has a simple designed website & API that can be queried in tooling like in VSCode's Editor or via cli tooling.

This I feel would allow for better adoption of DSC & is something that somewhere in the PackageManagement Repo I know I commented that I wanted this in future for modular configurations across OS'es when you have core similar apps & settings that you want to configure.

I have the design below for the Package Resource, and if this is something that others think is of use & would like to see I am willing to raise another issue with a suggested design (Infrastructure and Site Architecture) for the Package Registry, including the required metadata that the package registry should have.

Proposed technical implementation details (optional)

ResourceName - Microsoft.DSC/Package

Available Resource Properties

FUID: 
PackageName:
PackageID: 
PackageVersion:
PackageMinVersion: 
PackageMaxVersion:
PackageVersionRange:
InstallSource:

Examples of this would then be

Example 1 on Ubuntu using snap as an example

PackageName: PowerShell
PackageID: pwsh
PackageVersion: LTS
InstallSource: snap

Example 2 on default install source for OS

FUID: Microsoft.PowerShell.Preview

Example 2 on default package manager

FUID: Microsoft.PowerShell.Preview

Example 3 on Windows not using WinGet

PackageName: PowerShell-Preview
InstallSource: chocolatey

Example 4 on Windows using WinGet by default

PackageName: PowerShell
PackageVersion: LTS 

Example 4 on Windows using WinGet & custom source

FUID: Microsoft.PowerShell
PackageVersion: LTS
InstallSource: InternalWingetRepo

Example 5 from GitHub Releases

FUID: Microsoft.PowerShell
PackageMinVersion: 7.5.2
InstallSource: GitHub Releases

Note this should not then install any pre-releases or any other release that is not on that Minor versionm so no 7.6.x or above

No files, tests, or entry points are named in the issue. Start by surveying the DSC resource model and package-management integrations, then define a minimal proof of concept for Microsoft.DSC/Package and the registry API; done means a cross-platform resource can resolve the listed package, version, and source fields and the registry can be queried by CLI or VSCode tooling.