Support augmentation-declared constructors and methods.

[srawlins]

The gist of this is to not just ask an Element for it's methods and for its constructors, but make sure to ask the augmented element, if there is one.

Work towards #3693

Again, we still cannot check in tests as we cannot depend on _fe_analyzer_shared or analyzer from the Dart SDK, or use the correct macros import. But with this code, we get the following features:

• augmentation-declared constructor is shown in the sidebar; same for augmentation-declared method,
• augmentation-declared constructor is shown in a class's page; same for augmentation-declared method,
• augmentation-declared constructor has it's own page; can be linked to from a doc comment; is linked to from the class's page,
• augmentation-declared method does not have it's own page yet; cannot be linked yet.

A few fixes are made additionally:

• While working on this, I saw that a crash would mean that the AnalysisContextCollectionImpl was never disposed. So I tidied that all back into PackageBuilder. It can not be the PackageBuilder's caller's responsibility to dispose, because that amounts to have a dozen places in tests.
• In the code that gathers inheritance info, we also need to make sure to grab an element's augmented declaration, if there is one.

---

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