when an incorrect character that can not be interpreted by
the JavaCC Token Manager is encountered.

Actually, the TokenMgrError thrown by JavaCC is caught by all
ADQLParser.parseQuery(...) functions, wrapped inside a ParseException
which is finally thrown instead of the TokenMgrError. In this way,
ADQL-Lib users just have to care about a single Throwable:
ParseException.

Besides the error message has been slightly modified from:

> Lexical error at line 1, column 10.  Encountered: "\u00e9" (233), after : \"\"

to:

> Incorrect character encountered at l.1, c.10: \"\\u00e9\" ('é'), after : \"\"

Thus, the error is more user-friendly, more easy to understand by users.
Additionally, the incorrect character is displayed, as before, in its unicode
expression, but also in its character form (instead of an integer value that
nobody can really understand).

This commit fixes the GitHub issue #17

(https://github.com/gmantele/taplib/commit/7a70c6038cef460ab169682bed391bb5ae1de1e9)

It was not possible to use a GROUP BY with a qualified column name.
So finally, now, a GROUP BY is a ClauseADQL<ADQLColumn> instead of
a ClauseADQL<ColumnReference>. Indeed, according to the ADQL's BNF,
GROUP BY items are only columns as they would appear in the SELECT
clause (i.e. qualified or not, delimited or not). On the other
hand an ORDER BY accepts ONLY column index or non-qualified column
name/alias.

The class ColumnReference is kept for backward compatibility (or in
case the next version of the ADQL grammar make items of GROUP BY and
ORDER BY of the same type: index or qualified column). Besides, this
class is still inherited for the ORDER BY clause items
(see adql.query.ADQLOrder).

a qualified column name should be allowed, but still no column index should be.

Two classes have been modified after compilation:
    - ADQLParser - a simple cast for one of the automatically generated
                   constructor.
    - ParseException - the token position has been stored for better
                       syntax error messages.
A note has been added at the top comment for both files to highlight
the modified parts and how to restore them after re-generation.

The "normal" JOIN:
    A JOIN B ON A.id = B.id JOIN C ON B.id = C.id
is correctly interpreted as:
    ( (A JOIN B ON A.id = B.id) JOIN C ON B.id = C.id )
But with a NATURAL JOIN, the tree is mirrored:
    A NATURAL JOIN B NATURAL JOIN C
gives:
	( A NATURAL JOIN (B NATURAL JOIN C) )
instead of:
    ( (A NATURAL JOIN B) NATURAL JOIN C )
This is not a problem when the SQL translation is identical to the ADQL
expression, but for some DBMS a conversion into a INNER JOIN ON is necessary
and in this case we got the following SQL:
    A JOIN B JOIN C ON A.id = B.id ON B.id = C.id
Which seems to work, but is syntactically strange.

This commit should fix the generated tree. A "normal" JOIN and a NATURAL JOIN
should now have the same form. A JUnit test has been added into TestADQLParser
to check that: testJoinTree().

clause SELECT.

Before this commit, unsigned integers were also allowed (as for ORDER BY).

Because of a test of the first parameter (non existing for functions
like PI() and RAND()), a NullPointerException was thrown and so
was stopping brutally an ADQL query interpretation.

[ADQL] Fix a Big Bug reported by M.Taylor and M.Demleitner: in ORDER BY, GROUP BY and USING only regular and delimited identifiers are accepted, not qualified column names.
For instance: "SELECT table.column_name FROM table ORDER BY table.column_name" is wrong. We should instead write:
"SELECT table.column_name FROM table ORDER BY column_name".
"SELECT table.column_name AS mycol FROM table ORDER BY mycol" is also correct.
Of course, for ORDER BY and GROUP BY, it is still possible to reference a column using its index in the SELECT clause.
For instance: "SELECT table.column_name FROM table ORDER BY 1".

[ADQL] Fix the ADQL DEBUG mode ; now ADQLParser.setParser(boolean) is doing what it is supposed to do.

[ADQL] Fix merge side-effects (e.g. '' were not translated any more as a single ' ; NullPointerExceptions when building positions) + transform the test main class for positions into a JUnit test case + Fix some position mistakes.
(note: a tabulation character seems to be interpreted by JavaCC as 8 characters)

[ADQL] Fix DEBUG mode in the ADQL parser. It is still by default disabled, but now, it is possible again to enable it using the function 'setDebug(boolean)'.

Replace uses of String.isEmpty and Arrays.copyOf methods
(both introduced in java 6) with equivalent code that makes
use of only methods available in the java 5 runtime.
This allows the ADQL library, if cross-compiled for java 5,
to run without errors on a java 5 runtime.

[ADQL,TAP] Add STC-S and UDFs support in the ADQL parser. Now, it is possible to provide a list of allowed UDFs, regions and coordinate systems. The ServiceConnection of TAP is now able to provide these lists and to propagate them to the ADQLExecutor. UDFs and allowed regions are now listed automatically in the /capabilities resource of TAP. The type 'geometry' is now fully supported in ADQL. That's why the new function 'isGeometry()' has been added to all ADQLOperand extensions. Now the DBChecker is also able to check roughly types of columns and UDFs (unknown when parsing syntactically a query). The syntax of STC-S regions (expressed in the REGION function) are now checked by DBChecker. However, for the moment, geometries are not serialized in STC-S in the output....but it should be possible in some way in the next commit(s).

ADQLObject has now a new function: getPosition(). To allow it, the parser and all ADQL query tree item have been modified to define this function properly. The parser is setting this position for all parsed items. The test class/main function "TestGetPositionInAllADQLObject" aims to check that after a parsing all items really have a defined position.

1/ let the function ROUND having 2 parameters
2/ wrap Operations (WrappedOperand) with brackets when there are brackets in the ADQL query

ADQL: Fix an ADQL bug (raised by Dave Morris) in the management of subqueries: before, it was impossible to use (in a clause different from the FROM) columns of a father query inside a subquery.