gh-152708: Fix AST generation asymmetry for unary positive in match statements

[Twix1288]

This PR fixes an asymmetry in AST generation where a unary positive in a pattern match expression (e.g., case +0:) was parsed directly as a Constant (implicitly dropping the + sign), whereas a unary negative (e.g., case -0:) correctly generated a UnaryOp(USub, Constant). This led to round-trip parsing inconsistencies with ast.unparse.

Changes:

1. Grammar/python.gram: Updated the rules for signed_number, signed_real_number, and imaginary_number to retain + prefixes as _PyAST_UnaryOp(UAdd, ...), restoring parity with - behavior.
2. Python/ast.c: Refactored the AST pattern matching validator ensure_literal_negative into ensure_literal_signed to permit both USub and UAdd unary operations in literal matching.
3. Python/ast_preprocess.c: Added support for folding UAdd operations recursively within fold_const_match_patterns so that the compiler optimizer correctly resolves unary additions to positive constants without triggering compiler validation syntax errors.

Fixes #148566

• Issue: ast.parse creates only Constant(value=0) nodes for a case +0: pattern, which is inconsistent. #152708

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[JelleZijlstra]

Does this affect the bytecode generated for this code? If so, we likely shouldn't change this in 3.15.

[Twix1288]

Yeah, I'm 100% sure. Basically, the parser used to just silently drop the + in stuff like +1 in match cases, and now we make it properly keep it as a UnaryOp node. Then, in ast_preprocess.c, we just fold that node back into a plain number. Because the optimizer ends up seeing the exact same value it always did, it spits out the exact same LOAD_CONST bytecode.