Refactor swayfmt to support arbitrary lexed trees

[ironcev]

Description

This PR refactors swayfmt to be able generate code from arbitrary lexed trees. Arbitrary means a lexed tree that can be fully or partially created in-memory by manipulating the tree structure in code. It does not need to necessarily be backed by source code. This is needed to be able to reuse swayfmt for generating source code from tools that analyze and modify Sway code, as explained in #6779.

This PR makes the swayfmt independent of spans backed by the source code, by doing the following changes:

• Keywords are rendered by using theirs AS_STR associated constants.
• The Token trait is extended with the AS_STR associated constant, and tokens are rendered by using that constant.
• Idents are rendered by using theirs as_str() methods. This method takes the textual implementation from Ident::name_override_opt if it is provided, and ignores the span in that case.
• Literals are rendered based on the literal value and not their spans. The exception are numeric literals that do not have empty spans. Those are considered to be backed by source code and are rendered as written in code, e.g., 1_000_000u64.

The PR also fixes some existing bugs in swayfmt:

• use path::{single_import,}; will be formatted as use path::single_import;
• use path::{a,b,}; will be formatted as use path::{a, b};
• partial addresses Properly handle annotations everywhere in swayfmt #6802 by rendering annotations for final values.
• partial addresses Properly handle Punctuated without trailing comma everywhere in swayfmt #6805 by properly rendering final values, but still not using the expected field alignment.

The PR also removes the path parameter from the parse_file. It was used only to provide an unnecessary dummy source_id which was always pointing to the package root file.

Closes #6779.

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).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• 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.

[codspeed-hq]

CodSpeed Performance Report

Merging #6806 will not alter performance

_{Comparing ironcev/6779-refactor-swayfmt (6d536d2) with master (76c060b)}

Summary

✅ 22 untouched benchmarks

[JoshuaBatty]

Nice one @ironcev great work with this. Being able to format in memory structures is a great addition. Just a couple of code nits with trailing , in the macros.

[ironcev]

@alfiedotwtf Thanks for such a detailed review of token definitions! To keep this PR focused, I propose to have these potential changes as a separate PR, and combine it with the redefiniton of the & token which we already know we need to do to support references to references, e.g., &&&T.

I've opened a separate issue for that: #6808. Is this ok for you?

[alfiedotwtf]

I've opened a separate issue for that: #6808. Is this ok for you?

My comments may not have been correct, but creating a new issue so we don't derail this PR is a good idea :)

[alfiedotwtf]

I've got no other suggestions to the PR. With my write!() comments, let's ignore it for this PR so I'll approve now, but I think it could be worth testing out that possible big optimisation win.

[bitzoic]

No more commas!