Add parsed_to_ast fn in sway_core

[JoshuaBatty]

This PR refactors compile_to_ast and adds a parsed_to_ast function. This avoids reparsing the whole program again in the language server when doing the type-checking phase as we can call parsed_to_ast with our already obtained CompileResult<ParseProgram>.

[otrho]

We have a couple of these little functions now, like parsed_to_ast, compile_to_ast and compile_to_asm. We should look at cleaning up the public interface -- it seems every little step in the pipeline is useful to either tooling or testing, so they all might as well be publicly exposed.

[mitchmindtree]

This should probably be:

Suggested change

	parsed: CompileResult<ParseProgram>,
	parsed: ParseProgram,

To make this change, we'll also need to change the compile_to_ast body to:

    parse(input, build_config).flat_map(|parsed| {
        parsed_to_ast(parsed, initial_namespace)
    })

---

The CompileResult's flat_map method should probably be called and_then to better align with the std Option and Result methods, but that's a future PR.

[JoshuaBatty]

But don't we still want to carry any errors and warnings across from the parsing stage?

[mitchmindtree]

The result returned from sway_core::parse should have already been handled by the user as they likely require access to the ParseProgram within the result (otherwise they would have just called compile_to_ast in the first place).

[JoshuaBatty]

Thanks @mitchmindtree I've changed parsed_to_ast to take a ParseProgram instead of a CompileResult<ParseProgram>.

I've also tried to retain the original behaviour of carrying forward any warnings and errors found during the parsing stage when calling compile_to_ast.

[mitchmindtree]

Agh I forgot CompileAstResult isn't just an alias for CompileResult<TypedProgram>, so you couldn't have used the CompileResult::flat_map method anyway.

🚢

[otrho]

Yeah, it gets a little complicated in lib.rs as we have 2 or 3? different 'result' types and error types. Again, might be worth revisiting in a future refactoring.

[otrho]

You might be able to use check!() in compile_to_ast rather than destructuring the result from parse() but that doesn't let you dedup the errors... but that might happen later anyway? I can't be bothered checking. This is fine. 🙂