Fix parser/lexer ambiguity for CONTAINS function

[teunvanhemert]

Currently, the grammar does not properly accept this scenario:

SELECT
    CONTAINS(o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/sometext, 'test') AS containsValue
FROM
    EHR e CONTAINS COMPOSITION c[openEHR-EHR-COMPOSITION.encounter.v1]

This is caused by ANTLR recognizing the CONTAINS function call in the SELECT clause as a CONTAINS instead of a STRING_FUNCTION_ID, as CONTAINS is defined earlier in the lexer.

The 'reuse' of non-fragment lexer symbols in this way is not really supported by ANTLR without resorting to rather complicated solutions, so I suggest just extending the definition of the functionCall parser rule a little, as this PR does.

[sebastian-iancu]

@teunvanhemert, oddly enough I just now noticed this PR.
Your change is good, I will merge it, but first I also need to document it properly in JIRA.