adding release.yml workflow for maturity assessment

[rex-schilasky]

Description

THIS IS SUMMARIZED WITH CHATGPT:

What this workflow does
When you push a Git tag matching v* (e.g. v1.2.0), it will:

1. Create (or update) a GitHub Release draft for that tag
2. Gather “quality artifacts” (README, documentation URL, plus any test results, coding guidelines, release‑process notes you configure) into a manifest via the Eclipse “quevee” action
3. Upload the generated manifest as a release asset on the draft Release

This gives Eclipse’s badge‑review tooling a single, machine‑readable file listing all the evidence you’ve provided.

---

What still needs doing before it works end‑to‑end

1. Populate all artifact inputs

   • Right now only artifacts_readme and artifacts_documentation are set.
   • You’ll need to point artifacts_requirements, artifacts_testing, artifacts_coding_guidelines, artifacts_release_process (and any others) at your actual files or URLs.

2. Decide on release strategy

   • We currently do releases manually. This workflow does auto‑create a draft Release via softprops/action-gh-release@v2, so we can keep our manual tagging flow—but if we decide to use a different release‑automation action, we need to swap that in.
   • Whatever we choose, we need to make sure a draft (or published) Release exists for each v* tag so that both the “quevee” and “upload‑release” steps can attach assets to it.

Once those pieces are in place, merging this PR will give you an end‑to‑end, tag‑driven badge pipeline for Eclipse maturity assessment.

END OF CHATGPT

For my understanding we need to add the needed quality artefacts and finally this workflow run needs to run for every release that we tag - manually or automated.