Store comment reference data on ModelNode

[srawlins]

This is work towards #3798.

The analyzer is now tagging Comment nodes with references with various static elements, all backed by the new @docImport syntax, via a new DocImportScope (see https://dart-review.googlesource.com/c/sdk/+/345361 and https://dart-review.googlesource.com/c/sdk/+/353232). But they're not available in the element model. So while we have the syntax nodes, in PackageGraph, we must "side-car" the data, by storing it in separate classes (with no references to any AST nodes).

So in this change we introduce the CommentReferenceData class, attach instances to ModelNode.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[srawlins]

CC @dart-lang/analyzer-team

[bwilkerson]

LGTM, assuming that the possible overwrite issue isn't really an issue.

[bwilkerson]

I haven't thought about this deeply like I'm sure you have, but at first glance this appears to be prone to having information overwritten if it's possible to have two comment references with the same name that resolve to different elements.

For example, could a reference to a parameter in one method and a parameter with the same name in a different method cause the map to tell us that both references refer to the second method's parameter? Or a similar question about references to type parameters?

[srawlins]

Good question! Since this get data is made available on a single Comment, each reference in square brackets with the same name must refer to the same thing. Like in

/// Text [foo] and [bar] and [foo].

There is never a change to the scope within a doc comment, so [foo] and [foo] always refer to the same element.

And then the Map of CommentReferenceData is not merged with any other maps from any other comments. It is just stored in a ModelNode for the documented element.