Support UPDATE ... FROM and preserve source-qualified assignments

[kosiew]

Which issue does this PR close?

• Closes UPDATE ...FROM bug #19950.

Rationale for this change

UPDATE ... FROM was previously rejected or behaved incorrectly because joined assignment expressions were not preserved end-to-end. In particular, source-table references such as t2.b could be lost during planning, which meant updates either failed outright or used the wrong values when applying joined assignments.

This change fixes that gap so UPDATE ... FROM works for the supported single-source-table form and produces the expected target-row updates. It also aligns filter extraction and assignment handling with the semantics users expect from joined updates, including aliased target/source tables and self-joins.

What changes are included in this PR?

This PR adds end-to-end support for UPDATE ... FROM across SQL planning, physical planning, and MemTable execution.

At a high level, the changes include:

• removing the SQL planner restriction that rejected UPDATE ... FROM

• extending DML planning to project both:

  • the new target-row values, and
  • a hidden copy of the original target-row values using __df_update_old_* columns

• adding TableProvider::update_from(...) as a dedicated API for providers that need precomputed joined update rows

• implementing update_from(...) for MemTable

• matching replacement rows back to original target rows using the projected original-row image

• preserving source qualifiers for multi-table update assignments while keeping existing single-table UPDATE behavior

• improving DML filter extraction so only target-table predicates are forwarded to providers in UPDATE ... FROM and self-join cases

• resolving join partitioning before handing joined update plans to table providers

• adding helper utilities and documentation for hidden original-row column naming

Are these changes tested?

Yes.

This PR adds and updates tests across SQL planning, physical planning, provider behavior, and sqllogictest coverage. The new tests cover:

• logical planning for UPDATE ... FROM, including projection of hidden original-row columns
• preservation of source aliases in joined assignment expressions
• single-table UPDATE qualifier stripping behavior remaining unchanged
• correct extraction of only target-side predicates for UPDATE ... FROM
• alias variants and self-join cases
• successful execution of joined updates against MemTable
• regression coverage for duplicate matches, which now surface as an error when replacement rows do not map cleanly to target rows
• related DELETE filter-extraction cases to keep DML behavior consistent

Are there any user-facing changes?

Yes.

Users can now run supported UPDATE ... FROM statements successfully in DataFusion, including cases with aliases and joined assignment expressions such as:

UPDATE t1 AS dst
SET b = src.b, d = src.d
FROM t2 AS src
WHERE dst.a = src.a;

This is a functional improvement to SQL behavior. It also introduces a new TableProvider::update_from(...) hook for provider implementations that want to support joined updates.

LLM-generated code disclosure

This PR includes LLM-generated code and comments. All LLM-generated content has been manually reviewed and tested.