Strong-name sign all packaged assemblies

[wieslawsoltes]

Summary

Strong-name sign every first-party assembly currently shipped from a packable project.

This restores the repository's existing signing policy to the three Avalonia packages whose signing imports were commented out and applies the same policy to the newer Uno packages.

Root cause

Svg.Skia already keeps a strong-name key and central build/SignAssembly.props settings, and most packages import them. Five packable projects did not:

• Skia.Controls.Avalonia
• Svg.Controls.Avalonia
• Svg.Controls.Skia.Avalonia
• Svg.Controls.Skia.Uno
• SvgML.Uno

The Uno control also exposes internals to its test assembly. Once the production assembly is signed, .NET requires that friend assembly declaration to include the full public key and that the test assembly be signed with the matching key.

Changes

• enable the shared strong-name settings in all five previously unsigned package projects
• sign Svg.Controls.Skia.Uno.UnitTests with the same repository key
• qualify the Uno test InternalsVisibleTo declaration with the matching public key

All affected assemblies now use public key token dafe96fe6c845a74, consistent with the rest of the package family.

This addresses strong-name assembly signing, matching the request and prior #19 implementation. It does not add Authenticode publisher signing, which would require a separately managed trusted code-signing certificate.

Impact

Consumers that require strong-named dependencies can use the Avalonia and Uno packages without encountering unsigned Svg.Skia assemblies. The change also makes assembly identity consistent across the complete first-party package set.

Validation

• dotnet format Svg.Skia.slnx --no-restore
• dotnet build Svg.Skia.slnx -c Release --no-restore
• dotnet test Svg.Skia.slnx -c Release --no-restore
  • 3,109 passed
  • 40 skipped
  • 0 failed
• verified all five affected Release DLLs with sn -T and sn -vf

Fixes #535