fix: prefer generic call interpretation for f<T>(x) via prec.dynamic

[VladimirMakaev]

Summary

• Adds a _generic_call_expression rule with required type_arguments and prec.dynamic(1) to resolve the <> generic-vs-comparison ambiguity
• When the GLR parser forks on < (could be type_arguments or comparison operator), the generic call path now has higher dynamic precedence
• The rule is aliased to call_expression so the output tree is unchanged
• A separate rule is needed because prec.dynamic on the full call_expression (with optional type_arguments) would also boost trailing lambda calls, breaking object literal class_body parsing and getter/setter accessor recognition (12 test failures)

Before

f<T>(x)  // parsed as: (f < T) > (x)  — comparison chain

After

f<T>(x)  // parsed as: call_expression(f, type_arguments(<T>), value_arguments(x))

Follows the pattern used by tree-sitter-java (prec.dynamic on generic_type) and tree-sitter-go (prec.dynamic on type_arguments).

Parser size

Branch	parser.c size	Change from main
main	25,505,362 B (24.3 MB)	—
After accessor fix	28,666,529 B (27.3 MB)	+12.4%
This PR (cumulative)	28,775,213 B (27.4 MB)	+12.8%
This PR (incremental)	—	+0.4% over accessor fix

The prec.dynamic variant adds minimal parser states (+0.4%) since the GLR conflict infrastructure already exists.

Test plan

• All 241 existing corpus tests pass (zero regressions)
• Object literals, anonymous functions, getter/setter accessors unaffected
• f<T>(x) correctly parses as generic call
• if (x < y) still parses as comparison
• npm run cross-validate shows no regressions