Deprecating the legacy analyzer plugin system

[srawlins]

The new analyzer plugin system seems to be humming along nicely (all of the bug reports and feature requests are a good thing, right?). Barring unforeseen complications, we should be able to deprecate the legacy analyzer plugin system, whose primary client was @rrousselGit 's custom_lint. So we need to consider that plugin carefully when planning this deprecation. And after a deprecation period, we can start removing the legacy plugin system.

The primary motivations here are (a) simplify our story to just have one plugin system with one set of documentation, API, packages, etc. And (b) to simplify maintenance of the Dart Analysis Server.

I think a broad timeline would be:

1. Decide that the new plugin system is robust enough that we can deprecate the old. I think this mostly means:

   • Are existing custom_lint authors more-or-less satisfied with the new system?
   • Can existing custom_lint packages more-or-less be converted to new plugins?

   I'd like to say "The new plugin system has perfect feature parity with the old system (minus intentional removals like the ability to offer autocompletion suggestions)," but some level of pragmatism is probably required.

2. In some Dart SDK release (as early as Dart 3.12), deprecate use of legacy plugins. This means:

   • Announcing in the CHANGELOG. Probably mentioning in the blog post as well, if there are other notes about analyzer plugins.
   • Reporting use of a legacy analyzer plugin when specified in analysis options (really, anything in the analyzer/plugins section; new plugins are specified in a new top-level plugins section).
   • Flagging legacy analyzer plugin usage loudly in the "analyzer insights" pages.

3. In a later Dart SDK release (maybe as early as the following release), disable legacy plugins. As soon as we land this code, we can start deleting the supporting code. Maintenance of the Dart Analysis Server does not get any more simplified until this step.

Specific tasks:

• [ ] Get a read from users on whether the new system is stable enough to remove the old.
• [ ] Start reporting any usage of legacy plugins as Deprecated.
• [ ] In the Insights pages, start flagging any usage of legacy plugins as Deprecated.
• [ ] Disable running legacy plugins.
• [ ] Simplify AnalysisOptions code to not support legacy plugins.
• [ ] Simplify/refactor code in plugin_manager.dart, plugin_watcher.dart, plugin_isolate.dart.
• [ ] Evaluate the tests in plugin_manager_test.dart which have been disabled for years.
• [ ] I think remove plugin_locator.dart.
• [ ] Aggressively refactor the analyzer_plugin package code. Details can be hashed out when we get here, but some guidance: For the legacy plugin system, this package was the primary API for writing plugins. For the new plugin system, there is a very small set of code that makes up public API (edit builders and range factory and... this and that). Every piece of code in this package should be either (a) moved into the analysis_server_plugin package, (b) deleted, or (c) moved into the analysis_server package. If an element should be available for new plugins, then it should be moved to the public API of the analysis_server_plugin package. If an element is not public API, but is required by other code in analysis_server_plugin, it should be moved to the private API of that package. If any element is no longer needed by plugins, but is still needed for DAS (like maybe types or other stuff necessary for autocompletion), it should be moved to the analysis_server package. And there are probably a handful of elements (or many!) that can be removed. Documentation in the doc/ directory should be addressed carefully.
• [ ] The above changes should not require new releases of the analyzer_plugin package. Once it's gutted, we can archive the package.
• [ ] (Alternatively, we can "rename" the analysis_server_plugin package to be analyzer_plugin, since the former is a rather unwieldy name. But... this is fairly significant churn... and not really necessary as part of this process.)