Bound recursion depth for chained operators, not just nesting

[afonsojanu]

base() already refuses to parse expressions nested more than TE_MAX_DEPTH deep. Looking at the comment there, that limit exists specifically to keep te_eval(), te_free() and the constant-folding pass in te_compile() from overflowing the stack, since all three recurse over the parsed tree once per level.

The guard only fires when parsing recurses through base(), though, which covers parentheses and function arguments but not a long run of same-precedence operators. "1+1+1+...+1" builds a parse tree exactly as deep as the equivalent chain of nested parens would, without ever going through base(), so it slips right past the check. A few hundred thousand terms is enough to crash the process with a stack overflow inside optimize(), before the caller even gets a chance to call te_eval().

Repro before the fix, built with -fsanitize=address:

$ ./repro 200000
compiled: (nil) ...
==...==ERROR: AddressSanitizer: stack-overflow ... in optimize tinyexpr.c:916

This PR adds the same depth check to the other combinators that build chains iteratively (term, sum_expr, rel_expr, eq_expr, and_expr, expr, list, and both variants of the ^ chain in factor), so they fail with a clean parse error past the limit instead of building an unbounded tree. Since the arguments to a multi-arg function call are evaluated independently of one another rather than nested inside each other, I reset the depth budget between arguments so two legitimately-deep-but-separate operands (e.g. atan2() of two 400-deep nested expressions) don't get penalized for each other's depth.

Also added a couple of cases to test_depth() in smoke.c: one that builds a long operator chain per existing depth bucket and checks it's rejected past 500, and one confirming that two independently nested function arguments still succeed. Ran the full smoke suite (both the default build and the TE_POW_FROM_RIGHT/TE_NAT_LOG variant) under ASan+UBSan; all 10094 checks pass.