feat: auto-import for sway

[sdankel]

Description

Closes #4782

Notes

This implementation relies on the diagnostics that are provided in the context of a code action request. Conveniently, only the diagnostics related to the symbol in the request are provided in the context. Since we also need the name of the symbol to look up, I added a DiagnosticData type to the metadata that is published with diagnostics. For the errors that indicate a missing symbol, this data is attached, and then used to look for possible imports when the code action request handler runs.

• Added ProgramTypeKeyword symbol kind to distinguish them from other keywords
• Added submodules_recursive to lexed and parsed modules because LSP wasn't collecting tokens inside of nested submodules. This implementation comes from typed module, I just made it generic via the HasSubmodules and HasModule traits.
• Added TyIncludeStatement to the compiler, and span and mod_name to IncludeStatement to populate it. This was needed to identify where the end of the last mod statement is in the file.
• Added span to UseStatment and TyUseStatement so that we can replace an entire Group statement with the new one. e.g. use a::b::{C, D, E};
• Added CallPath to several of the typed tokens that were missing it.

Testing

• integration tests for each type of item that can be imported
• unit tests for the location of the generated import in the file

Limitations

I found several bugs / edge cases where auto-import doesn't work:

• enum variants: When enum variant is missing import, it should contain the enum's span #5188
• std-lib functions: LSP: Missing tokens for std lib functions #5191
• std-lib constants: LSP: auto-import not working for std-lib constants #5192

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.

[sdankel]

Just tested this locally with the test example. Seems each import into the deep_mod use statement added a new line leading to a large gap between it and the next use statement. Are we able to avoid this?

Good catch! Fixed.

[JoshuaBatty]

🚀

[IGI-111]

LGTM but I do insist on that name change as people seem to be easily confused about the fact that CallPath values from the typed AST are not guaranteed to be valid top level fullpaths, which this explicitly needs to be as I understand the usage.

[sdankel]

LGTM but I do insist on that name change as people seem to be easily confused about the fact that CallPath values from the typed AST are not guaranteed to be valid top level fullpaths, which this explicitly needs to be as I understand the usage.

It doesn't need to be a full path actually, since I end up calling to_fullpath on it anyway. It's just there for symmetry with the other types (TyEnumDecl, TyStructDecl) to make the code more consistent.

[IGI-111]

Ah never mind that then