Review #2339 for code improvements: an unknown column takes its value from a different table per row #2680

This is not a bug report. It is an invitation to look at #2339 again, because the way it finds a column can take values from different tables in different rows. The goal is to understand the change and decide whether anything should be improved. The notes below come from a quick read of the diff and a few runs, not from a full analysis.

The concern:

• "The first source where the value is not null" decides per row. For a column of a join whose table is unknown at compile time (inline data), Fix SELECT returning undefined for columns from joined inline data #2339 reads p.a.id ?? p.b.id. Since Fix unqualified columns of joined subqueries in expressions to close #832 #2579 the same rule lives in Column.fromAnySource (src/50expression.js) and serves expressions too. When both sources have the column, a row where the first one is NULL silently takes the second one's value:

  alasql('SELECT id, x FROM ? a CROSS JOIN ? b', [[{id: null, x: 1}, {id: 2, x: 2}], [{id: 5}]]);
  // [{id: 5, x: 1}, {id: 2, x: 2}]: id from b in the first row, from a in the second

  SQLite refuses the query (ambiguous column name: id), and AlaSQL refuses it in an expression when the tables declare their columns (Built-in functions read an unqualified column from the first table in a JOIN #2615).

• Deciding by "the first source that has the key" ('id' in p.a) rather than by its value would keep each row in one table. Refusing when more than one source has it would match SQLite, but that part is breaking (Built-in functions read an unqualified column from the first table in a JOIN #2615 is in 5.0).

Related: #832, #1985, #2579, #2615.