Refactor issue_key function to sort issues in a human-friendly way

[SmileyChris]

Description

In the issue key sorting method, there's this comment:

        # Maybe we should sniff strings like "gh-10" -> (10, "gh-10")?

Let's do that.

To be more backwards compatible, we'll continue putting just plain numbers last. In reality, it's very unlikely a project is mixing issue types, but if they are, then they'll be grouped:

>>> sorted(["2", "#11", "#3", "gh-10", "gh-4", "omega", "alpha"], key=issue_key)
['alpha', 'omega', '#3', '#11', 'gh-4', 'gh-10', '2']

Checklist

• [x] Make sure changes are covered by existing or new tests.
• [x] For at least one Python version, make sure local test run is green.
• [x] Create a file in src/towncrier/newsfragments/. Describe your change and include important information. Your change will be included in the public release notes.
• [x] Make sure all GitHub Actions checks are green (they are automatically checking all of the above).

[SmileyChris]

I am not sure what an "issue" is: news fragment vs ticket ID

@adiroiban I actually decided to switch to issue rather than ticket. My logic is it's the only term actually used in code and changing it for consistency would be backwards incompatible.

We use the issue_format configuration option and the issues_by_category context argument when rendering.

Even though it's not your preference, are you ok with using "issue" across the board instead of ticket?

[adiroiban]

Thanks for the update

Even though it's not your preference, are you ok with using "issue" across the board instead of ticket?

Sure. No problem.

Your suggestion is much bettter.

Happy to see some improvements here

Thanks