Replace `DidExtractionFunction` with `DefaultDcpParticipantIdExtractionFunction`

[arnoweiss]

WHAT

Currently, the dataspace-protocol-core extension still checks for a MembershipCredential when extracting the counterparty's identity. Thus, it's not Dataspace-agnostic. Every DataspaceProtocolContext can have only a single ParticipantIdExtractionFunction. It's not desireable to register a new DataspaceProtocolContext for each new Dataspace that's differentiated only by their Credential-Constraint Profile.

WHY

Not every Dataspace will have a MembershipCredential

HOW

Replace the current class with the upstream DefaultDcpParticipantIdExtractionFunction. That way, the id property of the first VC in the VP is used. The cryptographic holder binding (all vc.credentialSubject.id properties are equal to vp.iss) is verified elsewhere.

FURTHER NOTES

My preference would be to use the vp.iss property as participant id but that's not possible with the current stack of the upstream ProtocolTokenValidator, DcpIdentityService and ClaimTokenCreatorFunction. That would cover the case where a VP contains no VCs.