feat: add id and type to match interface

[TimoGlastra]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

Introduces a new id and type property on the SubmissionRequirementMatch interface that allows better matching of a match object to the related input_descriptor or submission_requirement.

If the match is for an input descriptor (in case there are no submission_requirements) the type property will be SubmissionRequirementMatchType.InputDescriptor and the id property will be the id of the input descriptor

I the match is for a submission requirement, the type property will be SubmissionRequirementMatchType.SubmissionRequirement and the id property will be the index of the submission requirement in the submission_requirements array (this is the only unique thing I could find to link back to the submission requirement entry, there is no required id field or something). This also works for nested submission requirements. In this case the outer match id is the outer index in the submission requirement, and the inner match id is the index within the from_nested array (this can recurse endlessly).

Although adding these properties is not a breaking change, I did change the behaviour of the name property as well. Currently this was set to the name or id of one of the input descriptors, even if the match is for a submission requirement, which leads to confusion and doesn't make sense IMO. So if the match is for a submission requirement (for input descriptor behaviour stays the same) I now updated that to be either the name of the submission requirement, or undefined if there submission_requirement has no name. You can use the id property to locate the submission requirement associated with the match.

One thing we lose here (but basically wasn't present before as well) is that you now don't know which input descriptor(s) the credentials in a submission requirement match are from. So if a group "E" can either accept a cred from input descriptor "A" or "B" you now just know that the credentials in the list match group "E", not which input descriptor they came from

I see this as a great additional feature for a follow PR (it will be non-breaking extra metadata, but should somehow be linked to the vc_paths, as there can be vcs from different input descriptors in the match list)

This fixes #116 as well as #161 (on the PEX level, there will be changes required in Credo as well)

The changes in tests mostly come from now also expecting the new properties, the change in code are quite minimal

[DJHunn39]

Suggested change

	private getMatchingVcPatchsForSubmissionRequirement(
	private getMatchingVcPathsForSubmissionRequirement(

[TimoGlastra]

Hey @nklomp any chance you can take a look at this PR? :)

[nklomp]

As I am on holiday, will defer to @sksadjad who should be back after the weekend, or @sanderPostma

[TimoGlastra]

Thanks!