Pipeline to check release note number is issue

[PeterNerlich]

Motivation

We have a script to create new release notes, which are saved as [ISSUE NUMBER].yml and automatically compiled into a list of changes that link back to the original issue on release. This is primarily done in order to be transparent to users about changes and bug fixes. Users will mostly find issues useful, as they might be a level higher than the description of and discussion in PRs, which can often get very technical.
It might be beneficial to add a pipeline to ensure the number provided for a release note is actually designating an issue instead of the PR.

Proposed Solution

Add a CI pipeline / step to merges into develop to check if the number designates either an issue or a PR where either no or more than one issues are mentioned in the description (not the whole discussion) for any release notes affected by the PR. This is to allow quick fixes without separate issues, but still prefer a concrete issue to be mentioned.
As a bonus this should also check that any release note belonging to this PR is inside the unreleased/ directory, not any existing release.

Alternatives

• Add such a check to new_release_note.sh. This ignores people creating or manipulating release not files directly and gives no feedback to reviewers. E.g. I personally am guilty of not using the script because I don't want to set another token for the gh tool.

User Story

As a developer I want maximum freedom and control in creating and managing release notes, but would appreciate a small automated reminder at the end before merging the changes.
As a reviewer I would appreciate getting such a reminder as a separate check in GitHub.

Additional Context

#3018 has several PRs with release notes referencing the PRs instead of the original issues. This is a simple developer oversight, especially as they have no functional bearing anywhere in the system and are thus invisible. Moreover, linking to PRs is (and imho should be) explicitly supported – issues should only be preferred.