Try to avoid reserving keyword used only within query clauses not at start

[jclark]

Issue #1136 deals with keywords that start query clauses but are not used elsewhere.

There are also keywords used in query clauses other than at the start:

• equals in join clause
• ascending, descending in order by clause

We should try to make them not reserved.

[ushirask]

For a case like

DeptPerson[] deptPersonList =
       from Person person in personList
       join var dept in deptList
       on equals dept?.id    // missing identifier before equals
       select {
           fname : person.fname,
           dept : dept?.name
       };

by making equals non-reserved we would get a missing equals keyword instead of missing identifier since equals will be considered the identifier in this situation. @hasithaa @lochana-chathura

[lochana-chathura]

xyz NR means the characters xyz literally, and xyz is not a reserved keyword

Does this means we can use xyz anywhere as an identifier? i.e. even within the context where xyz could be a keyword. e.g.

    int[] ints = [];
    int[] evenNums = from int where in ints
        where where % 2 == 0 // here we are using `where` as an identifier in the same context
        select where;

if above is the case, we have a problem when its comes to error recovery / diagnostics / Language server completions. e.g.

from Person person in personList
where  <cursor>
select person

Consider user is trying to write where-clasue as per the above scenario. Previouly parser gave an error saying missing identifer after the where keyword.

Now that we allow select as an identifier, parser parses select as the where-clasue's expression and then gives an error saying missing select keyword, which is ugly.

Therefore, I think we should disallow using contextual keywords as an identifier within the context. This would disallow using contextual keywords as identifier within other constructs if that contruct is within a query-expression.

[jclark]

@lochana-chathura This is a separate point from this issue. I've moved it into a new issue #1259.