feat: add KeyLocker signing action for NuGet packages

[SondreFjaertoft]

yo, her e et forslag fra me og young copilot om endring av sign til windows builden og henting av ny cert fra keylocker. Dinne skal være trygg å merge til main uten at det skal skje så mye,.. men u know.. alt kan skje... Neden for e liten forklaring av det som e blitt gjort og kordan få testa

This PR adds DigiCert KeyLocker support to the reusable .NET publish workflow while keeping the existing PFX signing path as fallback. It is intended to be safe to merge before DigiCert credentials are available.

What changed:

Added a new Windows-based signing path using DigiCert KeyLocker.
Added a new internal action for KeyLocker NuGet signing.
Kept existing PFX signing as automatic fallback if DigiCert secrets are missing.
Made the old PFX secrets optional at the workflow boundary.
Ensured publish/release fail closed if signing is expected but does not succeed.
Important behavior:

If DigiCert secrets are not present, the workflow should continue using the current PFX signing flow.
Nothing should break after merge as long as the existing PFX secrets still exist.
DigiCert is only used when these secrets are added:
SM_API_KEY
SM_CLIENT_CERT_FILE_B64
SM_CLIENT_CERT_PASSWORD
SM_CODE_SIGNING_CERT_SHA1_HASH
Important note about the cert secret:

SM_CLIENT_CERT_FILE_B64 is not the signing cert private key.
It is a client authentication certificate used to log in to DigiCert.
The actual signing key stays in KeyLocker.
What to test later when DigiCert creds arrive:

Add the four DigiCert secrets.
Run a release-like or sign-packages flow.
Confirm logs show KeyLocker is used instead of PFX fallback.
Verify package signing, Artifactory push, and integration-test trigger still work.
Main intent:

Merge now safely.
Keep existing behavior unchanged until DigiCert credentials are available.
Enable someone else to test the KeyLocker path later without redesigning the workflow.