AST Factory API for plugin compatibility

Problem

Plugins that create AST nodes instantiate them from their own bundled copy of brighterscript. When the host app runs a newer version, the plugin's AST nodes come from the older version and miss bug fixes, compatibility changes, or new required fields introduced in the host version.

Example:

• plugin-alpha depends on brighterscript 1.2.0
• Host app uses brighterscript 1.3.0
• plugin-alpha calls new CallExpression(...) — that instance is from 1.2.0's class, not 1.3.0's

This creates subtle bugs that are hard to diagnose.

Possible Solution:

Maybe expose a factory API on program that plugins use instead of direct constructors:

program.factory.createCallExpression(callee, args, ...)

Since plugins already hold a reference to program throughout their lifecycle (received via events like BeforeProvideProgramEvent, AfterValidateProgramEvent, etc.), this is the natural attachment point — no new plumbing needed on every event type, and the factory's lifetime is tied to the correct host instance.

Scope

• Define a factory class with a createXxx method for each AST node type (expressions, statements, etc.)
• Attach it as program.factory
• Each factory method is the stable API contract — constructor signatures can evolve independently without breaking plugins
• There will be some duplication between the AST class constructors and the factory methods; this is intentional and necessary to maintain a stable interface
• Document that plugins should use program.factory.createXxx(...) instead of new Xxx(...) when creating AST nodes

Notes

• The factory doesn't replace the constructors; it wraps them behind a stable interface
• Consider versioning or capability-checking so plugins can detect which factory methods are available
• Consider how to handle xml vs brs vs other future ast. Do we have a subsection category first? prefix with the type? factory.createBrsCallExpression? factory.brs.createCallExpression? Just dump them all together and hope for no collisions?

Start by tracing the program instance passed through BeforeProvideProgramEvent and AfterValidateProgramEvent, then review the existing AST node constructors. Define the factory surface and AST categorization or capability strategy before implementation. Done means program.factory exposes the intended node creators and plugin documentation describes using it instead of direct constructors.