Expose all AST creators to plugins to prevent stale/invalid AST generation

Problem

Currently, plugins in brighterscript may create AST nodes using internal constructors, which can become outdated or incompatible as brighterscript evolves. This poses a risk because plugins may inadvertently construct old or broken versions of AST nodes if they're not using the latest creators directly from the core brighterscript package.

This issue was highlighted in rokucommunity/rooibos#358, where mixing versions between rooibos (which bundled its own bsc) and the host brighterscript led to malformed test output. The root cause was the plugin constructing AST nodes with outdated logic.

Proposal

Expose all of brighterscript's AST creator functions (such as for ClassStatement, MethodStatement, DottedGetExpression, etc.) to the plugin API surface. This ensures that plugins can reliably create up-to-date AST nodes, preventing subtle bugs caused by mismatched structures and eliminating the need for hacky workarounds (like leveraging hidden constructors).

Benefit

• Plugins will always generate AST consistent with the host's current brighterscript version.
• Avoids subtle breakages and hard-to-debug issues for plugin maintainers.
• Makes brighterscript's plugin API more robust and future-proof.

Reference

See the context and workaround discussion in rokucommunity/rooibos#358.

Start by tracing the plugin API surface and the existing AST creator functions for ClassStatement, MethodStatement, and DottedGetExpression. Identify which creators are not publicly exposed and determine how the plugin API exports them. Done means plugins can access all AST creators from the host brighterscript package without hidden constructors or bundled-version workarounds.