Python: fix(python): fix operator precedence and associativity in WorkflowState fallback evaluator - #10329

Motivation & Context

When PowerFx is not available, WorkflowState.eval() falls back to _eval_simple(), which evaluates formulas by splitting the string on operators. That approach gets And/Or precedence wrong, treats - and / as right-associative, and matches operators inside string literals, causing formulas to silently produce wrong values (repro cases in #10162). This change replaces the string-splitting logic with a small parser so the fallback agrees with PowerFx on the documented expression subset.

Description & Review Guide

• What are the major changes?
  • Replaced string splitting in _eval_simple() with a tokenizer and precedence-climbing parser (Or < And < comparisons < + - < * / < unary !/Not()/negation), left-associative at every level, with (...) grouping while skipping string literals and comments.
  • Raised _UnsupportedExpressionError (a ValueError) for expressions outside the documented subset instead of returning incorrect results.
  • Preserved existing tolerant behaviors (None as 0 in arithmetic, + string concatenation fallback, division by zero returning None, and echoing the formula on runtime errors).
• What is the impact of these changes?
  • Existing single-operator tests pass unchanged; two tests asserting the old echo behavior for & now assert the raise.
  • Added regression tests covering the four issue repro cases along with precedence, associativity, parentheses, and quoted strings.
• What do you want reviewers to focus on?
  • The precedence ladder and left-associativity in the parser chain, and raising vs. echoing for out-of-subset expressions.

Related Issue

Fixes #10162

AI Assistance

• No material AI assistance was used.
• This is an AI-assisted contribution. I reviewed, understood, and verified all submitted content and accept responsibility for it.

AI assistance details: Used AI to help analyze the issue, the Copilot plan, and draft the PR description. The code changes and tests were written, reviewed, and verified locally.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR links to an agreed issue with no competing open PR, or the Related Issue section documents a trivial-change or repository-automation exception.
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.