Use stable ID in resolution keys

[stevendarby]

@naugtur My proposal would only be what @adevine has already proposed further up:

my plan is to fork this repo (and happy to submit a PR back if so desired) and instead use ${via.url}|${via.name} for the key (or perhaps just parse out the last part of the URL that has the GHSA ID and use that).

In response to this, you suggested making it configurable:

I'd accept a PR allowing you to specify what constitutes a key in some config somewhere (tbd) that defaults to backwards-compatible.

I can raise an issue to propose what @adevine suggested but - just to check before I do that - would you not make the same suggestion again?

Originally posted by @stevendarby in #56 (comment)

[stevendarby]

@MylesBorins, a while ago you said in #56 (comment):

GitHub advisory ID will be stable. I'm working on getting rid of the mutability of the npm advisory ID.

Is there any update on getting rid of the mutability of the npm advisory ID?

[naugtur]

AFAIK they are considered stable. The problem is that a vulnerability report can get reissued if severity changes and under some other conditions so sometimes the variability propagates from there.

I'd be happy to work together on a solution to make IDs configurable.
The resolve file has a section fir rules and we could have a rule containing a list of fields to read from the audit that'd default to what it is now but allow choosing your own set of fields to identify things.