OCI: Define MediaTypes and decompression logic for nupkg/zip

まず、既存の OCI アーティファクトの pull パスを追跡し、tar および tar+gzip レイヤーがどのように処理されているかを確認します。nupkg および zip のメディアタイプを定義し、それらのレイヤーに unzip 処理を適用して、既存の形式に影響を与えずにネイティブの 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.