Combine the two implementations of "library canonicalization"

[srawlins]

I was shocked to find that we had two mechanisms for determining an element's "canonical library": ModelElement.canonicalLibrary and a PackageGraph._findCanonicalLibraryFor. They were not quite the same implementation, but the differences turn out to be uninteresting; the two implementations can be combined. This change removes PackageGraph._findCanonicalLibraryFor. This implementation was only used in the package graph to find the canonical element for a given element. That code can now just use ModelElement.canonicalLibrary. It requires a fair bit of refactoring all over:

• PackageGraph.findCanonicalModelElementFor previously accepted an analyzer Element, instead of a ModelElement, but almost all of the call sites used foo.element or some other expression that could easily be replaced with an access to a ModelElement instead of the correlated Element.
• Document ModelElement.definingLibrary, ModelElement.canonicalLibrary, ModelElement._searchForCanonicalLibrary.
• Simplify ContainerMember.computeCanonicalEnclosingContainer to stop unnecessarily special-casing extensions and extension types.
• Simplify lookup component of ModelElement._searchForCanonicalLibrary.
• Simplity ContainerMember.referenceGrandparentOverrides to not use sync*.
• Move the top-level findCanonicalFor function out of model_utils.dart and into inheriting_container.dart, the only code that uses it anymore.

• Thanks for your contribution! Please replace this text with a description of what this PR is changing or adding and why, list any relevant issues, and review the contribution guidelines below.

---

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

I don't really have the context for this, but assuming that the tests are adequate to catch any user-visible changes this might have caused, lgtm.