[4.x] Antlers: Improves custom variable assignment inside tags

[JohnathonKoster]

This PR improves an over-aggressive internal tag parameter check. This internal check looks for specific tag parameters that will modify the resulting scope in some way that causes the current renderer to be unable to handle the tag's results.

With the current over-aggressive check, the following simplified example:

{{ _the_count = 1; }}

{{ collection:articles limit="3" }}
    {{ _the_count += 1; }}
    Entry: {{ _the_count }}
{{ /collection:articles }}

would produce the following output:

Entry 1
Entry 1
Entry 1

The current check is over-aggressive since it will pass if the tag contains any parameter with the same name as an existing modifier. The refactored check will only pass if the tag has any of the following parameter names:

• as
• scope
• handle_prefix

The AntlersNode retains the existing hasModifierParameters method, even though internal use has been discontinued, because it's a public method and third-party code might be using it for template analysis.

For performance reasons, the AntlersNodeParser now directly conducts the new check and sets a public property on the node. This change helps avoid array lookups and additional method calls in a hot code path.

Note: this check exists to help decide if the runtime's current NodeProcessor instance can handle the tag's results instead of relying on the AntlersLoop class or parseLoop method on the tag instance. Both have severe performance implications with the runtime and reusing the node processor as much as possible is always preferred. However, things get complicated with the above list of tag parameters, where a new copy of the current scope is required to prevent unintended side effects.

The current behavior happens because the runtime cannot accurately detect/trace what is happening inside the AntlersLoop class or the parseLoop methods. A workaround for this behavior is to simply alias the results:

{{ _the_count = 1; }}

{{ collection:articles limit="3" as="oo_shiny" }}
    {{#
        This works because the runtime *can* trace the assignments across scope barriers.
        Even though the as will force a new renderer to be created, the runtime is still
        handling the iteration/looping itself, instead of the tag's parseLoop method.
    #}}
    {{ oo_shiny }}
        {{ _the_count += 1; }}
        Entry: {{ _the_count }}
    {{ /oo_shiny }}
{{ /collection:articles }}