fix: Handle EXECUTE without statement name

[Dandandan]

Which issue does this PR close?

• Closes panic on EXEC() / EXECUTE() with no name: Option::unwrap() on None in statement.rs #22197.

Rationale for this change

EXEC() and EXECUTE() can parse as Statement::Execute without a statement name. The planner previously unwrapped that optional name and panicked on user-supplied SQL.

What changes are included in this PR?

• Return a planning error when EXECUTE has no statement name.
• Add sqllogictest coverage for the malformed EXEC / EXECUTE forms from the issue.

Are these changes tested?

• cargo test -p datafusion-sqllogictest --test sqllogictests -- prepare
• cargo fmt --all
• cargo clippy --all-targets --all-features -- -D warnings

Are there any user-facing changes?

Malformed EXEC / EXECUTE statements without a name now return a planning error instead of panicking.

[kosiew]

@Dandandan

Looks 👍 to me
I have one small suggestion that could make the invariant handling a bit more consistent.

[kosiew]

One small suggestion: consider validating name before planning parameters. Right now, nameless forms with non-literal arguments can still fail during parameter expression planning before reaching the missing-name check. Moving the ok_or_else earlier would make all nameless EXECUTE syntax return the same actionable error and would encode the invariant a bit earlier in the flow.