Add release workflow

[roji]

@jeffhandley @jfversluis this adds a release workflow to the repo. In a nutshell, MEVD has its own workflow for building/testing/packaging (triggered only when MEVD-related files are touched), and then we have reusable release workflow that gets included (and can be included also from other non-MEVD workflows) that publishes whatever nupkgs were created.

A notable thing here is that we don't want all components in the repo to have the same version and be published together; each MEVD provider (plus obviously non-MEVD components) should ideally be publishable separately, based on its own needs. So I came up with a hierarchical tag system where pushing a tag named mevd/PgVector/v1.0.1 publishes the PgVector provider only, a tag named mevd/v1.0.2 publishes all MEVD providers, etc. Hopefully this makes sense and isn't overly-complicated...

@jfversluis many parts here are based on what's going on in CommunityToolkit.Aspire/MAUI - am not familiar with the various signing logistics, org secrets, etc. Can you give this a look to make sure it looks OK?

Once we get this merged, I'll push a v1.0.0-preview.1 for all providers.

[jeffhandley]

Everything in here looks solid to me. I worry a bit about the testability and recoverability though. Approving with the optional suggestion of augmenting the workflow to support additional triggers.

For modelcontextprotocol/csharp-sdk, I have a release workflow that runs nightly to push CI builds to GitHub's package repository, and then it also gets triggered on release publishing. Only with release publishing, it also publishes to NuGet. That arrangement has kept us confident that the release workflow is functioning as expected on a daily basis, with only that NuGet publishing step as the potential point of failure during the time of a release.

That workflow also supports manual dispatch for interactive runs that publishing to GitHub in case of needing to recover from failure and test the workflow.

modelcontextprotocol/csharp-sdk/blob/main/.github/workflows/release.yml

[roji]

Thanks @jeffhandley, makes sense. FWIW that's also why I wanted to have the build and test be one workflow, and the sign/release/publish part a separate one that's relatively thin (as opposed to a release workflow which also builds and tests, and therefore may go out of sync and fail when it's needed).

We can definitely add periodic/manual triggers for all this as needed, let's see how it goes.

[jfversluis]

Ha the hierarchical tags are much better than my suffix system 😄 I should remember that for a next time.

Otherwise looks good to me! Unfortunately the secrets and things will be a matter of just trying it out and see where we end up, this other than that this looks like it should do the trick.

[roji]

Thanks @jfversluis!