Intersphinx scheme diverges from `myst-parser`

[agoose77]

Description

MyST (CLI) uses myst: as the scheme for intersphinx references. Meanwhile, myst-parser uses inv:. On the face of it, I prefer inv: because intersphinx is something MyST supports, but is not first-class (i.e. we could do better). I believe @rowanc1 and I discussed this in a recent call.

If we're planning on improving upon intersphinx (let it be known that I don't fully conceive of what we would do here, it's just a possibility), then we might want to reserve myst: for this mechanism.

The problem as I see it is:

1. If we improve upon intersphinx, then users should be able to see a difference between intersphinx cross references and MyST-external cross references
2. If an external reference implements both kinds of reference, we might elect to prefer MyST over intersphinx.
3. If the logic to detect external reference types is flimsy e.g. subject to network effects, the build will not error but instead will fall back on intersphinx should the MyST lookup fail
4. The user will see a visually distinct result (see (1)) without any indication as to why.

Proposed solution

Therefore, I think we have the following sensible options:

1. Explicit intersphinx-like referencing at the scheme level:
   • Deprecate the myst: scheme until we've implemented it
   • Add support for the inv: scheme
   • Deprecate the references: frontmatter key
   • Add new sphinx-references: frontmatter key

     sphinx-references:
     python: https://docs.python.org/3.7/
     jupyterbook: https://jupyterbook.org/en/stable/

2. Explicit intersphinx-like referencing at the frontmatter reference level
   • Change references items to be objects:

     references:
     python: 
      url: https://docs.python.org/3.7/
      kind: intersphinx
     jupyterbook: 
      url: https://jupyterbook.org/en/stable/
      kind: intersphinx

Maybe this is too strict. Pinging @rowanc1 / @stevejpurves / @fwkoch on this.

[agoose77]

c.f. https://mep.mystmd.org/en/latest/meps/mep-0002/ for the link-scheme discussion.