Expose parsing functionality for possible interfacing with third-party code

[ta5een]

Summary

It would be nice if the crate(s) responsible for tokenising and parsing Helios source files (for example, helios_parser) provide a public interface for third-party libraries and binaries to use. Although the helios_parser::parse function serves as the main entry-point of parsing a Helios source file, one may need fine-grained control over the parser and lexer. This means structures like helios_parser::lexer::Lexer and helios_parser::parser::Parser should be made available outside the crate.

Benefits

• New utilities such as formatters may be possible to implement without having to be baked into the Helios compiler itself.
• A lot of tools such as linters and formatters require traversing syntax trees, so having one source of representation (with the helios_syntax crate) avoids repetition and confusion.
• Promotes flexibility and ease of synchronisation of these third-party tools and the compiler.

Drawbacks

• Requires extensive documentation for public-facing types and functions.
• Exposing internals means changes need to be thoroughly checked and audited to prevent breaking existing code.
• Helper functions and types may need to be established to allow users to interface their code with the Helios syntax tree.
• The parser needs to be more error-resilient and predictable to anticipate logic errors created by third-party developers from improperly implementing the interface (such as calling functions in the wrong order).

There may be more benefits and drawbacks than the ones listed above. I will update this post when I can think of more.