Fix issue #2353: Incorrect canonicalization of NATURAL JOIN with INNE…

[revitalkr]

…R JOIN in Snowflake dialect produces non-equivalent query
Closes #2353

The current canonicalization rewrites queries such as:

SELECT *
FROM t1
NATURAL JOIN t5
INNER JOIN t0 ON (t0.v1 + t5.v0) > 0

into:

t1 NATURAL JOIN (t5 INNER JOIN t0 ...)

This transformation is not semantics-preserving.

NATURAL JOIN implicitly generates join predicates based on all shared column names.
Moving t0 into the right-hand side of the NATURAL JOIN changes the set of visible columns, which may introduce additional implicit join conditions and lead to different results.

Minimal example (see issue for full repro):

SELECT *
FROM t1
NATURAL JOIN t5
INNER JOIN t0 ON (t0.v1 + t5.v0) > 0

Expected behavior:
The canonicalization should preserve semantics, e.g.:

(t1 NATURAL JOIN t5) INNER JOIN t0 ...

Fix:
Avoid right-associative parsing when NATURAL JOIN is present, ensuring that NATURAL JOIN is evaluated left-to-right.

Tests:

• Fixed the join_precedence test, which previously assumed incorrect Snowflake behavior.
• Verified the actual behavior against Snowflake.
• Updated the test to reflect the behavior observed in Snowflake.

[iffyio]

we seem to be removing test coverage for the feature supports_left_associative_joins_without_parens - I think we might want to replace the removal with something else? otherwise its not clear to me if/why we need to keep the dialect flag around

[revitalkr]

It is used for queries with join which is not natural join, there's a snowflake dialect test for it, also I added a test for it in my next PR in the common file which is using this feature