Check statusCategory instead of the resolution field for Jira issue status

[derda17]

Description

PR for #14347

The status category is mainly used to decide if a jira issue is active or not. If the status is undefined (this may happen for old Jira projects that have not migrated properly to status categories), the resolution is still being checked. So I kept the most of the original logic for backwards compatibility.
In the resolution check there were some attribute checks missing and the resolution object was compared to a string "None", this always returned False. I adapted this.

Test results

Added a JIRAHelperTest test suite, that test various combinations of status categories and resolutions.

Documentation

I could not find a documentation that needs adjustments. Let me know if there is one.

Checklist

This checklist is for your information.

• Make sure to rebase your PR against the very latest dev.
• Features/Changes should be submitted against the dev.
• Bugfixes should be submitted against the bugfix branch.
• Give a meaningful name to your PR, as it may end up being used in the release notes.
• Your code is Ruff compliant (see ruff.toml).
• Your code is python 3.13 compliant.
• If this is a new feature and not a bug fix, you've included the proper documentation in the docs at https://github.com/DefectDojo/django-DefectDojo/tree/dev/docs as part of this PR.
• Model changes must include the necessary migrations in the dojo/db_migrations folder.
• Add applicable tests to the unit tests.
• Add the proper label to categorize your PR.

[dryrunsecurity]

This pull request includes a sensitive edit to dojo/jira_link/helper.py flagged by the configured codepaths analyzer, indicating changes to a protected file path (see .dryrunsecurity.yaml to configure sensitive paths and allowed authors). The finding is marked as an error (failing severity) but not blocking.

🔴 Configured Codepaths Edit in dojo/jira_link/helper.py (drs_814381c1)

Vulnerability	Configured Codepaths Edit
Description	Sensitive edits detected for this file. Sensitive file paths and allowed authors can be configured in .dryrunsecurity.yaml.

We've notified @mtesauro.

---

Comment to provide feedback on these findings.

Report false positive: @dryrunsecurity fp [FINDING ID] [FEEDBACK]
Report low-impact: @dryrunsecurity nit [FINDING ID] [FEEDBACK]

Example: @dryrunsecurity fp drs_90eda195 This code is not user-facing

All finding details can be found in the DryRun Security Dashboard.