fix(sql): reject unsupported relation modifiers - #24758

Which issue does this PR close?

• Closes Relation planning silently ignores unsupported table modifiers #24754.

Rationale for this change

SQL should either do what the user wrote or explain that it cannot. Today, if no RelationPlanner claims a relation, the default path can silently drop modifiers such as TABLESAMPLE or VERSION AS OF and produce an ordinary table scan. That is especially surprising after an extension planner deliberately passes the relation through: a successful query may have different semantics from the SQL on the screen.

Real integrations show why this boundary matters:

• Paimon implements VERSION AS OF and TIMESTAMP AS OF.
• VGI implements TABLESAMPLE.
• Coral already rejects unsupported modifiers exhaustively in its own planner, so a sqlparser upgrade cannot quietly introduce another ignored field.

This PR puts the same safety net at DataFusion's default fallback boundary.

What changes are included in this PR?

• Keep the existing extension-first flow: a custom planner can still consume any modifier it supports.
• Make the default planner reject unsupported named-table modifiers, derived-table sampling, table-function WITH ORDINALITY, and table-function SETTINGS with clear errors.
• Destructure the affected TableFactor and TableFunctionArgs shapes exhaustively. A future sqlparser field now requires an explicit decision at compile time.

Are these changes tested?

Yes. The regression test exercises both fallback paths—without an extension planner and after a pass-through planner—and covers five representative forms across named tables, derived tables, and table functions.

I also ran:

• cargo fmt --all
• cargo clippy --all-targets --all-features -- -D warnings
• the contributor guide's extended workspace test command with the pinned test-data submodules initialized

Are there any user-facing changes?

Yes, intentionally: syntax that was previously accepted but ignored now returns a clear “not supported” planning error. Queries without these modifiers are unchanged, and extensions that consume a modifier before fallback continue to work as before.