Settle the CURIE prefix for PMCIDs in the JSON export's identifiers

[gaurav]

The JSON export's identifiers array now carries PMCIDs, and there is no
authoritative answer on what prefix they should use. We have shipped
PMCID:PMC7890668 as our best guess; this issue is to confirm or correct it.

What each source says

• Babel uses PMC — src/prefixes.py has PMC = "PMC". That would make the
  CURIE PMC:PMC7890668.
• NCATSTranslator/Babel#1044
  is itself unresolved on this point, so Babel's current value is not settled either.
• Core-Components-Working-Group#15
  (our normal tie-breaker) has no PMC example.
• The DocumentMetadataAPI README
  also has no PMC example.
• The production endpoint does not appear to support PMCIDs at all, under
  either prefix:
  https://docmetadata.transltr.io/publications?pubids=PMC:PMC7890668&request_id=26394fad-bfd9-4e32-bb90-ef9d5044f593

What we ship in the meantime

export.ID_PREFIXES maps pmc -> PMCID, so records read:

"identifiers": ["PMID:30690000", "PMCID:PMC6423490", "doi:10.1016/j.ejphar.2019.01.030"]

The doubled PMCID:PMC is expected — PubMed's ArticleId[@IdType="pmc"] values
already begin with PMC.

Resolving this

Settle it alongside Babel#1044, so whatever the compendium uses is what the
export emits; a mismatch means these CURIEs will not join.

Changing it is cheap and deliberately so: identifiers is derived at export and
never stored, so the fix is a one-line edit to export.ID_PREFIXES (the SQL and
validate's expected CURIEs are both derived from that mapping) plus a
re-export. No reload, no schema change.

• Get a ruling on the prefix, in coordination with Babel#1044
• Update export.ID_PREFIXES if it is not PMCID
• Ask whether DocumentMetadataAPI should resolve PMCIDs at all, and add a
  PMC example to the spec or the README once it is decided