[Unquoted Imports] Analysis Server Implementation

[kallentu]

This issue tracks all the analysis server work items for the unquoted imports feature. Referenced from: https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/doc/process/new_language_feature.md

WIP below. They have not been evaluated yet.

• Call Hierarchy (an IDE feature where you can get a call hierarchy if you
  click on a method)
• Closing Labels (an LSP feature allowing the IDE to show lightly grayed out
  comments at the end of the last line of a multi-line invocation, to aid
  the user in understanding what invocation is closed by a ))
• Code Completion
• Code Folding
• Document Colors (an LSP feature whereby a reference to a color in code can
  be associated with a colored swatch and a color picker)
• Hovers
• Implemented/override markers (a legacy protocol feature, only available to
  IntelliJ and Android Studio)
  • Implemented Markers (allows navigation from a base class method to
    methods that override it, or from a base class to classes that
    extend/implement it)
  • Override Markers (allows navigation from a method to the base class
    method it overrides, or from a class to the class that it
    extends/implements)
• Inlay Hints (an LSP feature allowing extra information to be displayed
  using inline hints)
• Navigation
  • Go to Definition (LSP feature)
  • Go to Type Definition (LSP feature)
  • Go to Super (LSP feature)
  • Legacy protocol (for IntelliJ and Android Studio)
• Occurrences
  • Legacy protocol (for IntelliJ and Android Studio)
  • Document Highlights (LSP feature)
• Organize Imports
• Outline
  • Flutter Outline
  • Legacy protocol, a.k.a. Document Symbols (for IntelliJ and Android
    Studio)
  • LSP feature
• Refactorings and quick assists/fixes (note that in addition to potentially
  creating new refactorings and/or quick assists/fixes, part of the work
  required to implement a new language feature includes evaluating each existing
  refactoring and quick fix/assist to see whether it needs to be improved or
  have test cases added to reflect the new feature).
  • Legacy refactorings (for IntelliJ and Android Studio)
  • LSP rename refactoring (note that LSP has a special protocol for
    renames)
  • LSP self-describing refactorings
  • Quick Assists
  • Quick Fixes
• Search
  • Find References
  • Implementations - LSP
  • Member Declarations
  • Member References
  • Top-level Declarations
• Selection Range (an LSP feature allowing a selection to be expanded to
  cover the range of an ancestor AST node)
• Syntax Highlighting
  • Legacy protocol, a.k.a. Semantic Highlights (for IntelliJ and Android
    Studio)
  • Semantic Tokens (LSP feature)
• Signature Help (an LSP feature that tells the parameters and types needed
  for an invocation)
• Snippets
• Sort Members
• Type Hierarchy
  • Legacy protocol (for IntelliJ and Android Studio)
  • LSP feature
• Workspace Symbols (LSP feature)

[FMorschel]

note that in addition to potentially creating new refactorings and/or quick assists/fixes, part of the work required to implement a new language feature includes evaluating each existing refactoring and quick fix/assist to see whether it needs to be improved or have test cases added to reflect the new feature

I'm aware this is still a WIP. I just have some questions to leave here as a reference for when we get to assists/fixes/autocomplete.

1. Will we have a lint for preferring this over the old style (important for the next question)? What about the other way around (not sure someone would want that but maybe - since there are some cases where this can't be used, maybe for consistency)?
2. Considering the first answer, would our current fixes/assists/autocomplete prefer this new syntax over the current one?

To map what I could find related to imports so we don't miss anything:

• Lints
  • always_use_package_imports
  • avoid_relative_lib_imports
  • conditional_uri_does_not_exist
  • implementation_imports
  • prefer_relative_imports
  • combinators_ordering
  • directives_ordering
• Diagnostics
  • ambiguous_import
  • ambiguous_export
  • deferred_import_of_extension
  • duplicate_import
  • duplicate_export
  • import_deferred_library_with_load_function
  • import_internal_library
  • import_of_legacy_library_into_null_safe
  • import_of_non_library
  • unnecessary_import
  • unused_import
  • uri_does_not_exist_in_doc_import
  • always_use_package_imports

We should probably add some "Good" code samples with this new syntax.

We may also need to add tests for:

• New assist to add/edit hide at import for ambiguous import #56830
• Add new "Go to Import" option #56584

If I missed anything else please mention.