Add support for dpid and IPFS for DeSci Labs Support

[yradwan147]

Description

Enhance IdentifierHelper to support Decentralized Persistent Identifiers (dPID) and InterPlanetary File System Content Identifiers (IPFS CID). Added methods for validation and extraction of dPID and IPFS CID, along with corresponding gateway domains.

Changes include:

• Added dpid and ipfs identifier types to IDENTIFIER_TYPES dictionary
• Added IPFS_GATEWAYS list with DeSci-optimized gateway ordering (ipfs.desci.com, pub.desci.com, dweb.link, ipfs.io, cloudflare-ipfs.com, gateway.pinata.cloud)
• Added DPID_DOMAINS list (dpid.org, beta.dpid.org, dev.dpid.org)
• Implemented is_dpid() and extract_dpid_id() methods supporting dpid:// scheme and dpid.org URLs
• Implemented is_ipfs_cid() and extract_ipfs_cid() methods supporting ipfs:// scheme, gateway URLs, and raw CIDv0/CIDv1 identifiers
• Added comprehensive test suite with 240 lines of tests covering dPID and IPFS CID detection, extraction, and integration with existing identifier types
• Updated repodois.yaml with new DOIs

Motivation and context

This enhancement adds support for decentralized science (DeSci) identifier standards to F-UJI, enabling FAIR evaluation of research objects that use dPID and IPFS CID as persistent identifiers. These identifier types are increasingly used in decentralized research data publishing.

How has this been tested?

• Added new test file tests/helper/test_identifier_helper.py with 240 lines of pytest tests
• Tests cover:
  • Valid dPID detection (dpid:// scheme, dpid.org URLs, beta/dev subdomains, version suffixes)
  • Invalid dPID rejection (non-dPID URLs, invalid formats)
  • Valid IPFS CID detection (ipfs:// scheme, gateway URLs, raw CIDv0 and CIDv1 identifiers)
  • Invalid IPFS CID rejection (invalid formats, wrong lengths)
  • Integration tests ensuring dPID/IPFS don't conflict with DOI, Handle, ARK, UUID, W3ID

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

Checklist

• I have read the contributor guide.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.