[Upsert] Fix issue with lambdas in DO UPDATE SET expressions

[Tishj]

This PR fixes #11827

What caused this error is that to avoid ambiguity between the expressions referring to the new data and the existing data (excluded.<column_name>) we qualify all of the references implicitly.

Where this breaks is in lambdas, because as we have seen, lambdas explicitly check that the column reference expressions in it are unqualified.

The fix is to not qualify the expressions inside the lambda.

[Mytherin]

I'm fine with this solution, but maybe @taniabogatsch wants to have a look at it as well when she is back?

[taniabogatsch]

I am okay with these changes, but I want to raise some concerns. 😅 If we merge this PR as-is, then we should maybe note in the ON CONFLICT DO UPDATE documentation that all parameters inside lambda expression must be qualified? Although the error message is helpful already.

INSERT INTO hello (SELECT 1, 72) ON CONFLICT DO UPDATE SET i = list_transform(list_value(j), x -> x + hello.i + j)[1]; 
Binder Error: Ambiguous reference to column name "j" (use: "excluded.j" or "hello.j")
# Fixed, j still unqualified outside of lambda
INSERT INTO hello (SELECT 1, 72) ON CONFLICT DO UPDATE SET j = list_transform(list_value(j), x -> x + hello.i + hello.j)[1];

This example shows that it is ambiguous for the user when to start qualifying parameters. The j we use outside of the lambda expression does not require qualifying, whereas inside the lambda, it suddenly does. I imagine that this becomes confusing for nested lambdas with other scalar functions, where suddenly everything must be qualified.

A cleaner solution would be to track/push all LHS lambda parameters before entering a RHS lambda expression, and only qualifying parameters that are not lambda parameters. When exiting the lambda expression, we pop them. Similar to the changes in this PR: https://github.com/duckdb/duckdb/pull/10150/files#diff-da6eafc29929607c29bd6b4393ee1c9b1505a77ca8e346e975bbeffa85ad80e8. See vector<unordered_set<string>> &lambda_params.

This approach might be more future-proof, but outside of the scope of this PR. If we stick to the current changes, let's add a comment to the code?

[Mytherin]

Thanks!