Improve self-hosting story for signed manifests

[kzu]

Instead of assuming other OSS projects will use our infrastructure, assume instead that they (being developers) will instead host their own endpoint for signed manifest generation. This should lower the bar for adoption since they can keep their sponsors information entirely private, while still emitting the manifest server-side and properly signed with their own private key.

This also makes it far more costly for malicious users intending to circumvent SL, since they would need to work around individually each package using it, rather than hacking a single manifest.

Features:

• A single GH CLI extension will still be the one emitting the entry point manifest (signed) for sponsorables to use
• A new endpoint in SL as backend to emit those sponsorable manifests for run-time seeding of manifest sync'ing
• A new per-sponsorable manifest should be downloaded instead of one for all
• Helpers for consumers would now read, cache and validate their own manifest individually.
• Make self-deployment of a server-side backend trivial for sponsorables. Perhaps a simple asp.net core net8.0 container that's deployed as-is and just needs a couple envvars for config?

[kzu]

This is all available and documented on main branch now. https://www.devlooped.com/SponsorLink/github.html#sponsorable-backend-self-hosting