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

• 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 #7054 will not alter performance

_{Comparing saimeunt:feat/enforce-const-type-annotations-5758 (c49b9f8) with master (c1b63c8)}

Summary

✅ 22 untouched benchmarks

[IGI-111]

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.