Enforce type annotations for constants

[saimeunt]

Description

This PR introduces a breaking change that requires all const declarations to have a proper type annotation.

This has been implemented by throwing a new parser error when detecting a constant declaration that lacks proper type annotation, and changing the ty_opt member of ItemConst to a non-optional type as it's no longer possible to omit it.

The ConvertParseTreeError::ConstantRequiresTypeAscription has been removed as it's no longer allowed to omit the type of a const and relying on the initialization expression to deduce it.

A new test has been added to make sure the parser errors when a const type is not explicitly stated.

The test raising the ConstantRequiresTypeAscription error has been modified to check for uninitialized associated const declarations instead.

A regexp has been used to find all occurrences of incomplete const declarations and try to patch them all.

Some other parts of Sway may be affected such as eg. sway-by-example: https://github.com/FuelLabs/sway-by-example-lib/blob/main/examples/constants/src/main.sw#L7

Closes #5758

Checklist

• [x] I have linked to any relevant issues.
• [ ] I have commented my code, particularly in hard-to-understand areas.
• [x] 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
• [x] 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.
• [x] I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• [x] I have requested a review from the relevant team or maintainers.

[codspeed-hq[bot]]

CodSpeed Performance Report

Merging #7054 will not alter performance

_{Comparing saimeunt:feat/enforce-const-type-annotations-5758 (845cb5f) with master (eb57cbf)}

Summary

✅ 22 untouched benchmarks

[saimeunt]

This all looks great and probably would work, but since it's a breaking change, it needs to be behind a feature flag.

Instead of doing that, which is a pretty significant amount of work especially if you're not familiar with the infra for those, I think a workable alternative so we can get this merged is to maintain the current behavior but reliably produce a warning (not an error) when a type is missing.

We'll easily be able to turn the warning into an error at a later date.

@IGI-111 Thank you for your review and your guidelines, I've slightly reworked the PR to change the previously introduced parser error into a warning.