Fix parser failure for character alias

[mweisgut]

This PR fixes a parser failure that occurs when an SQL string contains a character alias.

Example query:

SELECT student.id AS character FROM student;

The fault is related to the data type CHARACTER VARYING, which is a synonym for VARCHAR.
Before this PR, the scanner (Flex) matched the strings CHARACTER and VARYING to support CHARACTER VARYING. However, having CHARACTER as a token, the character identifier in the query above is matched with the CHARACTER token. Thus, parsing the query fails since the corresponding parser rule expects the IDENTIFIER token rather than the CHARACTER token.

Most flex programs are quite ambiguous, with multiple patterns that can match the same input. Flex resolves the ambiguity with two simple rules:
• Match the longest possible string every time the scanner matches input.
• In the case of a tie, use the pattern that appears first in the program.

Levine, J. (2009). Flex & Bison: Text Processing Tools. "O'Reilly Media, Inc.". Page 22.

For the above query, both the CHARACTER token and the IDENTIFIER token would match the longest possible string, which is character. CHARACTER is chosen over IDENTIFIER since it appears first in the program.

This PR removes the CHARACTER and VARYING tokens and adds a CHARACTER_VARTING token. This token matches strings with the following pattern:
CHARACTER<whitespace>*VARYING

[mweisgut]

If we want to support CHARACTER(N) in the future (#202), working with states in flex could be a possible option (see https://stackoverflow.com/questions/1130597/start-states-in-lex-flex).

[klauck]

I am totally fine with this version.
But normally, would we have to allow also newlines and comments between "CHARACTER" and "VARYING"?

[mweisgut]

Good catch. I added newlines at least.