Unifies autolink enrichment keys for integrations

[sergeibbb]

Description

Unifies autolink enrichment keys for integrations in order to avoid referencing the exact integration type outside of integratin class.

Updates the autolink enrichment workflow to consistently use a pair of values (id and key) when resolving issues or pull requests across integrations. This removes provider-specific logic for constructing enrichment keys and centralizes the approach, simplifying maintenance and reducing errors when linking to external systems.

Renames and refactors relevant methods in integration classes to reflect this unified signature. Enhances consistency and clarity in how autolinked items are identified and retrieved across supported providers.

Checklist

• I have followed the guidelines in the Contributing document
• My changes follow the coding style of this project
• My changes build without any errors or warnings
• My changes have been formatted and linted
• My changes include any required corresponding changes to the documentation (including CHANGELOG.md and README.md)
• My changes have been rebased and squashed to the minimal number (typically 1) of relevant commits
• My changes have a descriptive commit message with a short title, including a Fixes $XXX - or Closes #XXX - prefix to auto-close the issue that your PR addresses

[sergeibbb]

@axosoft-ramint @eamodio

I'm making this change because Linear is another integration that needs a full issue key rather than just <num>, that would require me to mention Linear integration in the autolinksProvider.ts as well as Jira was mentioned there. By this improvement we remove switching between from the autlinksProvider and move the decision down to the integrations because they know better what they want to use to retrieve data for the link.

[axosoft-ramint]

Looks good to me - one nitpick

[axosoft-ramint]

Should we update the cache function's name and parameter as well since this has been updated everywhere else?

[sergeibbb]

@axosoft-ramint
I'm not sure about that. Integration provider is smart while cache is stupid.

Integration provider is smart enough to understand why it have to pick among two incoming strings (id and key). So, when a developer creates, e.g. Gerrit integration it knows that it's a Gerrit. getLinkedIssueOrPullRequest() and picks a better value for retrieving the linked object by API.

While cache is just a key-value storage that stores issues or PR: Hey cache, take a key and give me whatever you have.

[sergeibbb]

@axosoft-ramint
well, now I'm thinking that maybe it's worth to add type (type?: IssueOrPullRequestType) to the cache key, because it plays role in the retrieving algorithm (in the provider-specific part of the method).

what do you think?