Add APIs for using analyzer element model 2.

[scheglov]

See https://docs.google.com/presentation/d/1Vxr-y5ljuo0Os78R4tKZg8cc0In984EQcLs06HOqS28/edit#slide=id.p for the new element model details. It is possible that you will not able access it, unless you work for Google.

This change is green in google3.

It looks that there are issues with dependencies and versions, and possible circular or chained dependencies.
And I don't know how to deal with these issues.

However google3 uses the version of analyzer that is newer than 7.0.0, so it is possible that 7.0.0 is not enough.
But because the the version issues mentioned above, I don't see, don't get to the place where it can be checked yet.
I have analyzer 7.1.0 publishing in flight, in case it is will be necessary.

---

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

[github-actions]

PR Health

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

[kevmoo]

How should we deal with #3774 here

Merge the effort?

[jakemac53]

I would really like to avoid propagating all the numbered variants of the APIs here, it implies a future breaking change to remove them, and build doesn't do many breaking changes (not since March 2021).

What is the plan for getting rid of the old APIs here? Or do we plan to keep them around for some time?

[jakemac53]

cc @natebosch in case you have any ideas for how to mitigate the maintenance/versioning costs here...

[natebosch]

I can't think of a way around a breaking version change here.

I'll spend some more time thinking of how we can most smoothly roll this out, but my initial thought is that it might bet better to separate the interface at a higher level than per-method. We should consider adding a Resolver2 (or same name but different import?) with the new APIs so that it's easier to avoid unintentionally mixing use. Having both available and neither is @deprecated could be confusing.

[scheglov]

Note, this change is a split-out of https://critique.corp.google.com/cl/698854756 where I migrated many clients of package:build and package:source_gen. And alternative way to do package:build API changes will require some rework on these pending google3 changes. I had to do this, to prove myself that everything works at the end. How do you usually plan changes like this? Do you also make google3 changes together with package:build changes? Do you plan doing something similar with these changes?

The old APIs in the analyzer will be removed after all the clients migrated.

[jakemac53]

In most cases, we would just do breaking changes externally (without publishing), then merge it into google3 (fixing up clients) before publishing. Externally we just expect version solving to solve this problem and don't expend a lot of effort to allow incremental adoption of new APIs.

This is harder though, when the change needs to trickle through many packages, such as the analyzer case.

However, I think it is probably feasible in this case. We still end up needing a breaking change it sounds like, but we don't need to introduce the new variant and then delete the old one, we can just do a single atomic swap of the types.

We would update the internal packages to be compatible with the new APIs and land that at the same time as rolling in the new package:build APIs. Then once that succeeds, we publish package:build.

[jakemac53]

@scheglov let me know if you want to just have a meeting to discuss

[jakemac53]

Discussed with @scheglov , we plan to have these apis temporarily just for the internal migration, but never to publish them (if we can avoid it). We will do an immediate swap to the new APIs as a breaking change, once the migration is complete.