minor: inconsistent group by position planning

[korowa]

Which issue does this PR close?

Closes #.

Rationale for this change

While #10591 found that planning for INT literals in GROUP BY clause is inconsistent. For example:

EXPLAIN SELECT "URL", COUNT(1) from hits GROUP BY 1, 3, 4, 5

produces following logical plan (this is logical plan before any optimizations):

Explain
  Projection: hits.URL, COUNT(Int64(1))
    Aggregate: groupBy=[[hits.URL, Int64(3), Int64(4), Int64(5)]], aggr=[[COUNT(Int64(1))]]
      TableScan: hits

1 resolved as column from select clause, and 3, 4, 5 remain as constants. Don't think this behavior is intended + there are couple of tests in sql_integration.rs (modified below), for similar cases, expect queries to fail.

The suggestion is to fail while planning phase for such cases, and return error, specifying first index which can not be resolved as select column.

What changes are included in this PR?

Resolution for positions (integer literals in GROUP BY clause) now returns error on first unresolved position.

SIgnature for resolve_positions_to_exprs changed to avoid unnecessary cloning. resolve_aliases_to_exprs signature has similar changes, for the same reasons (it's been changed just for consistency with resolve_positions_... function).

Are these changes tested?

Added sqllogictests + some test coverage for resolve_positions_to_exprs

Are there any user-facing changes?

Users might experience query planning failures for GROUP BY %idx% where idx is out of bounds of SELECT expressions list (which seems to be OK from SQL semantics point of view -- PG/MySQL handle this case in the same way).

[alamb]

Thank you @korowa -- this looks like a nice usability improvement to me.

I had a suggestion for improved message but I don't think it is needed

cc @jonahgao who I think is an expert in this area

[jonahgao]

Looks good to me 👍

I have verified that the behavior of this ordinal reference aligns with PostgreSQL.
The work to eliminate cloning is also great.

[alamb]

Thanks again @korowa and @jonahgao