[Chartjs][LiveComponent][Notify][React][StimulusBundle][Turbo][TwigComponent][Vue] Deprecate Twig functions/filters in favor of ux_ prefixed names

[seb-jean]

Introduce ux_<package> prefixed aliases for all Twig functions and filters across Symfony UX packages, and deprecate the old names to establish a consistent naming convention (following the pattern already used by ux_icon, ux_map, ux_is_native).

Q	A
Bug fix?	no
New feature?	no
Deprecations?	yes
Documentation?	no
Issues	Fix #...
License	MIT

[Kocal]

Hi, and thanks for working on this, but that's will be a big 👎🏻 to me.

Even though I understand the argument about naming conventions, I don't think it really matters here, other that adding friction (maintaining our code, doc, and users' apps).

Personally, I can’t see myself writing ux_twig_component() instead of component(), or ux_twig_provide() instead of provide(), for me it’s unnecessarily long.

I’m not saying it’s not an issue, but that it may have been approached the wrong way. Shouldn’t we be modifying our Twig ux_* functions instead?
It’s true that, on second thought, I’m no longer a fan of the names ux_is_native(), ux_calendar_link(), and ux_calendar_links (sorry @zairigimad 😅 ). I’m sure we can improve things by renaming them is_native_app(), calendar_links, and calendar_links(), for example.

On the other hand, I’m okay with changing render_chart() to ux_chart(). Just like we have for ux_icon() and ux_map(): Twig functions that take a DTO as input and generate HTML code, and which have an alternative component version (<twig:ux:icon> and <twig:ux:map>, but `<twig:ux: chart> does not exist)

WDYT?

[seb-jean]

Thanks for the feedback! (I didn't think I'd get such a big 👎🏻😅)

This PR actually originated from your own suggestion in #3462 (#3462 (comment)), where you recommended adding the ux_turbo_ prefix. That made me realize there was no consistency across the different UX components Twig functions, which is what this PR aims to address.

Regarding the verbosity concern (ux_twig_component() vs component()), I understand that it feels longer, but I think consistency across the ecosystem is worth the trade-off. Especially for new users discovering Symfony UX, where a clear ux_ prefix signals that a function comes from the UX ecosystem.

Moreover, there is a concrete technical reason to move in this direction: if tomorrow someone creates a new UX component that exposes a provide() Twig function, it will conflict with the existing provide() function from TwigComponent. With a ux_<package>_ prefix, this problem disappears entirely.