Validate dart_model for caching / performance

[davidmorgan]

@jakemac53 @scheglov @munificent @johnniwinther

In #93 I gave a quick rundown of the current state with dart_model and how it's ready for prototyping of macro metadata.

It's also pretty much at a point to start thinking about questions re: caching, invalidation and performance, some relevant issues: dart-lang/sdk#55784 and dart-lang/language#3868

In theory the query-based approach should fit well with invalidation+caching, this issue is about actually checking :)

I think probably for this one next steps are on me, as we have support for running a macro application with analyzer/CFE e2e but we're missing

• Support for iterating, i.e. for "apply, edit code, apply"; which is a critical case for benchmarking, and also is needed before we even have an idea what "invalidation" and "caching" mean
• Benchmarking :)

[scheglov]

Do we switch the analyzer and CFE to the new introspection and generation any time soon?

[davidmorgan]

If by "switch" you mean drop v1 and move v2 into the analyzer+CFE, then, not soon: v2 has a few end to end examples but is mostly incomplete.

We could choose to switch before it's complete, breaking v1 functionality; that might even be useful as it would reduce the amount of code being maintained. But there is also the question of dependencies and churn: it's useful to have this code be outside the SDK until it's stable; we need to either wait until it's stable or have a new strategy for allowing it to churn until it's stable.

At a high level I think we want to answer questions like performance, macro metadata handling and protocol/language/macro versioning as early as possible, well before v2 is complete. So "depth first" implementation in which we aim for e2e examples of the hardest parts first, not "breadth first" with full feature coverage :)