Rework Stalebot handling of issues to track releases

[joshuaboniface]

The Problem

Currently, our stalebot auto-issue-close functionality is purely time-based. This served us well in the past, but with our increased release velocity, continuously growing userbase, and Triage team expansion, I no longer think that pure time/activity-based auto-closing of issues is particularly useful or helpful.

The Idea

I'd like to see how we can modify stalebot to ignore issues that affect the current major release (major defined as digit 2, i.e. 10.10.z) while then providing a more helpful message and closing process for issues that affect older major versions.

1. Bot reads the version from the message when submitted, and appends a tag with the relevant major version (e.g. v10.10.z)
2. At each release, we update a global flag somewhere that marks the current release tag. This could be done by the release bot in the stalebot config directly, or via some other method.
3. We configure stalebot to ignore any issues that match the current release.
4. For issues that do not match the current release and have no recent activity (with a short window e.g. 2-4 weeks), stalebot sends a message like this and adds the stale tag:

   This issue affects an older version of Jellyfin (current version is 10.X.z). If this issue still affects the current version, please update the description. This issue will be closed in 30 days without further updates.

5. If the issue description is updated, we update the affected version tags and then stalebot would ignore it.

Alternate Proposals

@thornbill made a suggestion that instead of the above, we simply add a "stale release"/"old release" label to all open issues whenever a new major release is cut. However, I'm not entirely sure how feasible this is from an API layer as that is a LOT of API calls for the release bot to make. I'm not against the idea but it would need some testing to be sure. I also think that tagging issues with a version tag would be helpful anyways, so it might still be worth doing that.

Further feedback and ideas are welcome.