Make spiral/stempler a standalone templating library with built-in rendering support

[Yoskaldyr]

Description

spiral/stempler already contains the parser, AST, transforms, and compiler, but actual rendering support currently lives in spiral/stempler-bridge.

It would be useful to move the framework-neutral runtime pieces into spiral/stempler so the package can be used as a true standalone templating library, while framework integration can remain in the bridge package.

Proposal

Introduce a new standalone entry point in spiral/stempler called Stempler.

The goal of this class would be to provide a simple rendering API on top of the existing compiler pipeline, so users can compile and render templates directly from spiral/stempler without depending on Spiral Framework integration.

What makes sense to move into spiral/stempler

At a high level, it makes sense to move the framework-neutral runtime functionality that is currently in spiral/stempler-bridge, including:

• standalone rendering support
• builder/pipeline wiring that is currently assembled in the bridge
• cache support
• FlattenNodes
• FormatHTML

Notes

• Moving cache support into spiral/stempler would make the package more self-sufficient. It would also open the door to removing the dependency on spiral/files in the future by replacing it with a simpler internal filesystem abstraction or native PHP filesystem functions.
• FlattenNodes and FormatHTML are useful and frequently used post-processors, and they are framework-neutral, so they seem like a natural fit for the core package.
• It also makes sense to drop the dependency on spiral/core from spiral/stempler. At the moment it looks removable by replacing the two use Spiral\Core\Exception\LogicException; imports with native \LogicException.

Expected outcome

After this change, spiral/stempler would be usable as an independent library with built-in rendering support via Stempler, and the bridge package would remain focused on framework integration rather than hosting core runtime functionality.

[Yoskaldyr]

Another useful point: the rendering flow is currently split across two packages, which makes the runtime harder to evolve on its own.

If spiral/stempler becomes truly standalone, the template engine can be developed independently from the framework integration layer. That would make future runtime changes much easier, for example replacing the current ob_start() + echo rendering approach with a yield-based model or other streaming-oriented execution strategies.

In other words, this is not only about packaging convenience, but also about giving the engine a cleaner boundary and more freedom to evolve as an independent templating runtime.