Use GitHub Packages NuGet Registry

[FelixS90]

Description

Publish libczicompressc as NuGet to GH Packages Registry
Make czishrink consume libczicompressc as NuGet from GH Packages Registry

Fixes #26

As outlined in the issue above, this is intended:

• as a facilitator/enabler to Automate creation of THIRD_PARTY_LICENSES*.txt #7
• as an intermediate step to publishing to NuGet (potentially with the package having a different scope in what it contains)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
  Note: Dev/Deployment related breaking change only, no functionality-related breaking change!
  See https://github.com/ZEISS/czicompress/blob/26-use-github-packages-nuget-registry/czishrink/README.md#build
• This change requires a documentation update

How Has This Been Tested?

Cloud:
Manual pipeline runs of .NET Build (CziShrink) and CMake Build (czicompress)
Published libczicompressc as NuGet to GH Package Registry in CMake Build (czicompress) | Run 6883977121 - package
On Windows (locally):
Local nuget restore and dotnet restore
Local build + unit test execution
Manual test (start application)

TBD: Check #26 (comment)) (also in the context of https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions)

Checklist:

• I followed the Contributing Guidelines.
• I did a self-review.
• I commented my code, particularly in hard-to-understand areas.
• I updated the documentation.
• I updated the version of czicompress following the README (Versioning) depending on the type of change
  • Bug fix -> PATCH
  • New feature -> MINOR
  • Breaking change -> MAJOR
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.

[FelixS90]

Do it like https://www.fuget.org/packages/Microsoft.CodeAnalysis.PublicApiAnalyzers/3.3.2, i.e. only specifying commit (and not branch) - mainly to avoid issues with "hierarchical" branch names and full refs (like origin/refs/heads/). On top, branches are only pointers - commits are enough.

Background: NuGet/NuGetGallery#7537

[FelixS90]

owners deprecated.