HIVE-29783: Iceberg CoW MERGE INTO missing column ambiguity check in the ON clause

[ludlows]

What changes were proposed in this pull request?

here we want to check the columns in the ON clause of MERGE INTO syntax without being assigned table names
in case of copy on write table giving wrong results.
so, here we directly do not allow the unresolved columns in the ON clause to pass the check point.
the related issus is https://issues.apache.org/jira/si/jira.issueviews:issue-html/HIVE-29783/HIVE-29783.html .

The SQL used to reproduce the issue is like

-- source table 
CREATE TABLE src (a INT, b INT) STORED AS ORC;
INSERT INTO src VALUES (9, 10);

-- target table cow
CREATE TABLE tgt_cow (a INT, b INT)  STORED BY iceberg STORED AS ORC 
TBLPROPERTIES (
  'write.merge.mode' = 'copy-on-write'
);
INSERT INTO tgt_cow VALUES (9, 3), (2, 3);

-- target table mor
CREATE TABLE tgt_mor (a INT, b INT)  STORED BY iceberg STORED AS ORC 
TBLPROPERTIES (
  'write.merge.mode' = 'merge-on-read'
);
INSERT INTO tgt_mor VALUES (9, 3), (2, 3);

-- merge into mor
MERGE INTO tgt_mor 
USING src
ON a = src.a 
WHEN MATCHED THEN UPDATE SET b = src.b;
-- Expected: SemanticException: Column a Found in more than One Tables/Subqueries

-- merge into cow
MERGE INTO tgt_cow
USING src
ON a = src.a 
WHEN MATCHED THEN UPDATE SET b = src.b;
-- Not expected : Executes successfully without throwing an exception.

-- correctness checking after `merge` sql 
SELECT * FROM testcow
-- returns (9, 10), (2, 10)
-- The row (2, 3) was incorrectly updated to (2, 10) .

Why are the changes needed?

copy-on-write has a different write behavior with that of merge-on-read.
if we do not check the unresolved columns in the ON clause (make it a little more strict), the wrong logical plan is executed and produces wrong results.

Does this PR introduce any user-facing change?

No

How was this patch tested?

both negative and positive test cases are added.