OCI: Define MediaTypes and decompression logic for nupkg/zip

Summary of the new feature / enhancement

As a publisher, I want to publish PowerShell Modules packaged in nupkg as ORAS artifacts to consume in their native zip format rather than having to convert them to tar+gzip.

If I am hosting a large registry (e.g. https://pwsh.gallery), I can reference the same storage/packages for both nugetv2/v3 and oras packages, otherwise I have to hold and maintain duplicate copies/storage of every package.

Proposed technical implementation details (optional)

OCI allows definitions of both a media type and an image type. Rather then be generic, we should define types for both of these and implement them for nupkg/zip:

Nupkg MediaType: application/vnd.dotnet.nupkg.v1+zip

Zip Layer MediaType: application/vnd.oci.image.layer.v1.zip

When pulling packages, apply proper unzip to these layers and then handle the same as the tar+gzip. Potentially support a strict option to only accept items that were strictly published with the dotnet.nupkg mediatype.

This behavior would only occur on the specified image type, so it would not break any compatibility.

Registries could choose to then host powershell modules in either native zip, tar, tar+gzip, or tar+zstd.

This implementation would not require any registry-side changes, as they are designed for this and do not need to know or understand the zip format to work for both publishing and retrieval, unless a registry does some sort of non-standard validation of the artifact.

It may make sense to define these formats or the transfer mechanism in general in a PowerShell RFC so that all OCI-based PowerShell tools have a standard set of instructions to work from.

Start by tracing the existing OCI artifact pull path and how tar and tar+gzip layers are handled. Define the nupkg and zip media types, apply unzip handling for those layers, and verify that native zip packages are consumed without affecting existing formats.