parser recovery for let statements

[xunilrj]

Description

This PR closes #4911.

It primarily does two things:

1 - Extend a lot of functions that return CompileError to return Vec<CompileError> allowing multiple errors to return;
2 - Implements the concept of parser recovery.

This happens when using the function guarded_parse_with_recovery, exemplified below. When the guard fails, this function return Ok(None); when it succeeds it returns Ok(item). The exciting part is when the parsing fails.

It returns an instance of Recoverer which contains a reference to the original parser before any tentative parser was done and the forked as left by the parsing function.

The idea is that it is the caller's responsibility to put the forked parser in a "good position". For that, it offers some helpers function and access to the forked parser.

To avoid boilerplate code one recovery strategy is already implemented recover_at_next_line_with_fallback_error which consumes everything at the forked parser's current line and emits an error if none were generated by the tentative parser.

 match parser.guarded_parse_with_recovery::<LetToken, StatementLet>() {
        Ok(None) => {}
        Ok(Some(item)) => return stmt(Statement::Let(item)),
        Err(r) => {
            let (spans, error) =
                r.recover_at_next_line_with_fallback_error(ParseErrorKind::InvalidStatement);
            return stmt(Statement::Error(spans, error));
        }
    }

With this, we have the LSP not "dying" when a strange error happens. The errors themselves are not brilliant, but they will be improved in other PRs.

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.

[IGI-111]

I think the base structure is sound but the way the error handling is propagated needs to be rewritten, you shouldn't ever need to clear errors and warnings.