Support New Syntax to Declare Multiple Versions of the Same Dependency

[cmoesel]

NOTE: Proposed syntax has changed since this issue was reported. See latest comment below.

Some IGs may need to support multiple versions of the same dependency package. To support this, the following syntax will be used:

 "hl7.fhir.us.core-old" : "npm:hl7.fhir.us.core@3.1.1",
 "hl7.fhir.us.core" : "6.1.0",

SUSHI has been identified as a core tool that will need to support this.

For more information, see: https://chat.fhir.org/#narrow/stream/179239-tooling/topic/Advance.20Notice/near/439946498

[cmoesel]

Updated thread with updated example here: #tooling > NPM Aliases @ 💬.

dependencies:
  hl7.fhir.us.core:
    id: uscore7
    version: 7.0.0
    uri: http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core
    reason: |
      Defines USCDI v4 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers.
  v610@npm:hl7.fhir.us.core:
    id: uscore6
    version: 6.1.0
    uri: http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core
    reason: |
      Defines USCDI v3 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers
  v311@npm:hl7.fhir.us.core:
    id: uscore3
    version: 3.1.1
    uri: http://hl7.org/fhir/us/core/ImplementationGuide/hl7.fhir.us.core
    reason: |
      Defines USCDI v1 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers.

A few notes on implementation:

• This does not affect layout of fhir cache. Its only purpose is to avoid duplicate keys in the dependencies.
• The special dependency keys should be passed through to the IG JSON as specified.
• When multiple versions of the same package are specified, versionless references should resolve to latest. Currently this means that the latest packages should be loaded last (since we use last-in first-out resolution).
• The part before @npm: in the keys can be anything, as long as it follows FHIR id rules (/[A-Za-z0-9\-\.]+/).
• When the short-form dependency syntax is used, SUSHI should generate a guaranteed unique id.

[cmoesel]

This functionality is handled entirely by SUSHI now, so by the time SUSHI calls into FPL, it has already handled the aliases and just asks for the packages it needs using their normal package ids. See FHIR/sushi#1568.