ES|QL: implement name qualifiers for LOOKUP command

[astefan]

Description

{
  "query": "FROM employees | WHERE languages IS NOT NULL | SORT salary DESC | KEEP first_name, last_name, languages, salary | LOOKUP benefits ON languages | LIMIT 5",
  "tables": {
    "benefits": {
      "languages":    {"integer": [1, 2, 3, 4, 5]},
      "salary":       {"integer": [100,200,300,400,500]},
      "bonus_percent":{"double":  [5,7,9,11,15]}
    }
  }
}

resulting in

  first_name   |   last_name   |   languages   |    salary     |benefits.salary| bonus_percent 
---------------+---------------+---------------+---------------+---------------+---------------
Moss           |Shanbhogue     |3              |74970          |300            |9.0            
Tzvetan        |Zielinski      |4              |74572          |400            |11.0           
Lillian        |Haddadi        |1              |73717          |100            |5.0            
Valter         |Sullins        |2              |73578          |200            |7.0            
Remzi          |Waschkowski    |3              |71165          |300            |9.0            

[elasticsearchmachine]

Pinging @elastic/es-analytical-engine (Team:Analytics)

[luigidellaquila]

While benefits.salary could make sense (even though it's a breaking change), employees.salary seems a bit of a stretch.
A command should not change the names of existing attributes IMHO.

[astefan]

@luigidellaquila thank you for pointing that out. Indeed, there is a mistake in there: employees.salary shouldn't be there, only salary and benefits.salary. I've corrected it. There is also the point of qualifying bonus_percent or not, and there will likely be other open questions that can be discovered and addressed while implementing this feature.

[luigidellaquila]

Thanks @astefan
One additional thought: we'll have to deal with collisions anyway, so we'll have to define a strategy for them. Eg. benefits.salary is a valid field name, and it could be an existing field in employees schema