Remove use of NodeLocator2

[srawlins]

When we first resolve a library, we have full access to both the LibraryElement and the CompilationUnit (AST nodes) objects. We should use those pronto, rather than painstakingly recalculate them with NodeLocator2.

This is a pretty big ball of wax. But this is one step in untangling it. Almost everything we need to know about source elements in Dartdoc is on the element model, with two exceptions:

• Element documentationComment fields only contain the documentation comment text; it's a String. To get knowledge about comment references, we have to go back to the syntax tree.
• In order to extract the literal source code, to write in the "implementation" section of docs, we must use offsets only found in the syntax tree.

To hang onto some of this syntax tree data, without hanging onto any AST nodes, we do some pre-processing into ModelNode objects. This pre-processing is led by Library.fromLibraryResult. It used to use an ElementVisitor named _HashableChildLibraryElementVisitor. This is simpler now, and called _ModelNodeGatherer.

---

• 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.

[scheglov]

Why do we use visitor, if we just iterate manually?

[srawlins]

Well said! OK I've dropped the visitor, and made this a method on PackageGraph. Much simpler.