Handle expression aliases for RETURN and WITH clauses

[jmarton]

• update EMF model to accomodate expression aliases
• WONTFIX: in EMF model, change expression aliases from String to Variable. INSTEAD that, ExpressionVariable was introdiced to the relalg EMF model to accommodate maned expressions.
• handle name collision between model variables and alias variables (see explanation below in 2nd comment)
• handle in union (see Handle Union in opencypher2relalg compilation #9) either in cypher2relalg or at a later stage
• handle WITH clause
• handle WITH ... WHERE subclause (moved to Handle WITH...WHERE subclause #124)
• implement variable chaining

[szarnyasg]

My thoughts:

• The WITH and RETURN clauses should be handled as similarly as possible. Both can be sorted (ORDER BY) and both can define aliases with AS.
• For the aliases, there is a chance that the variables will be used later (especially for the WITH clause - the variables in RETURN can only be used for sorting). Therefore, I think expression aliases should be Variables instead of Strings (https://github.com/FTSRG/ingraph/blob/12e1fd7ce9a1f6bb24d1b713a40c1ac3c2dadaa9/ingraph-relalg-xcore/src/relalg.xcore#L82).

[jmarton]

@szarnyasg, it seems OK to make aliases variables.

However, for the compilation implementation, the following corner case also need to be handled correctly, i.e. return/with expression aliases hide variables with same name after all the return expressions are processed:

create (x0:AA {val: 0}), (x1:AA {val: 1}), (x2:BB {val: 2}), (x3:BB {val: 3});
match (n1:AA), (n2:BB)
return n1 as n2, n2 as n1
order by n1.val DESC, n2.val ASC;

This should result in:

       n2      |        n1
---------------+---------------
(:AA {val: 0}) | (:BB {val: 3})
(:AA {val: 1}) | (:BB {val: 3})
(:AA {val: 0}) | (:BB {val: 2})
(:AA {val: 1}) | (:BB {val: 2})

[jmarton]

Variable chaining is halfway with 1a425f1

[jmarton]

WITH ... WHERE seems challenging because in this WHERE clause, one need to take into account variables created in the WITH clause, but this does not apply for expressions present in a MATCH ... WHERE clause.

[jmarton]

WITH ... WHERE will be implemened in #124. Other than that, this is resolved, so closing it now.