Investigate replacement strategy for Smarty

[asmecher]

The Smarty templating engine is aging and will eventually need replacement. The clear leader is Blade (broad community use and aligns with our Laravel strategy), so I won't spend time here discussing alternatives.

Goals:

1. Determine a pathway for replacing Smarty with Blade throughout the codebase.
2. Determine best practices for adopting Blade.

These goals are in tension: a pathway to fully adopting Blade that aggressively converts our existing Smarty templates will necessarily move bad practices from Smarty over to Blade. We may need to have two parallel structures at once in Blade: one messy conversion from Smarty, and another clean (e.g. component-based) practice for new code.

Can Blade do everything that Smarty does?

Our Smarty use is not sophisticated. We:

• Register global variables with TemplateManager->assign. This can be replicated with Illuminate\Support\Facades\View::share.
• Register global functions with TemplateManager::registerPlugin. We can probably do this with Blade, but might not want to -- adopting explicit @use functions or just using the fully namespaced stuff might be better. (Blade does support aliasing, but that's typically done within the template with @use.)
• Include one template from another.
  • Including Smarty from Blade and vice versa should be trivial.
  • Including one Blade template from another is a well supported practice.
  • We probably want to keep it explicit which template engine is being used -- i.e. not extend Blade's @include or Smarty's {include} to make both work with either engine.

Proposed Strategy (2025-08-13)

• For now, we focus on adding good, clean Blade support for uncomplicated use cases -- plugins, for example. We can use these to develop a good Blade toolset and sample use cases.
• At the same time, we develop at least one new theme using Blade exclusively, with the intention of making this the future best practice.
• For the time being, Smarty support can remain undisturbed. We can decide on a deprecation/conversion pathway later.

Specific implementation will be worked out over at #9968.