Refactor special case for how canonical enclosing containers are calculated

[srawlins]

Work towards #3927

There is some complicated logic in the calculations for determining a canonical enclosing container, when we find ourselves examining a "hidden" interface. The list of "hidden" interfaces, which we should not consider when determining a canonical enclosing container, is exactly one: Interceptor. But it's important that it stay buried.

The logic was hard to read, so first, I split out a complicated if-condition into a few local variables. The logic also needs to track the "current" container in the inheritance list, and the "previous", and the "previous visible." This was complicated when using a for-in loop. I changed it to use a standard for loop with indices.

Then I saw that we only ever find outself asking a container for it's "memberByExample" in the case when we're looking for one of Object's members (toString, noSuchMethod, operator ==, hashCode, and runtimeType. We can inline the logic to fetch a member by example. This allows us to delete a late field on every Container.

Also, the package graph _invisibleAnnotations and _inheritThrough fields had very complicated initializers which I simplified with if-elements.

---

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

Ready for review, @dart-lang/analyzer-team