if the alias is not delimited in ADQL.

This commit fixes the GitHub issue #56

this table is declared with an alias. Instead, the table alias must be used.

Note: This problem occurred only when ADQLParser was used with a DBChecker.

This commit fixes the GitHub issue #53

A delimited identifier is any sequence of characters between a pair of
double quotes. For instance: "123 I am a delimited identifier!".

It is of course possible to have double quotes inside this kind of identifier,
but they have to be doubled in order to not be mistaken with the end of the
identifier. For instance: "Cool ""identifier""".

However, this escape option was not taken into account by the ADQL library,
though the same mechanism was already in place for string contants.

This commit resolves partially the issue #28

Ideally, there should be an implementation of UWSLog and TAPLog working with
Log4j and another for SLF4J (and eventually for other logging mechanism).
Additionally, an implementation storing log messages in database would be
interesting. All these ideas may be implemented in UWSLib and TAPLib in a
future version.

reserved word is encountered instead of a column/table/schema name/alias.

On the contrary to the previous commit, this time a list of SQL reserved words
has been added into the ADQL grammar. In this way, the parser will ensure that
no word of this list is used in an ADQL query. The raised error is then enriched
of an HINT message stating that this word is part of SQL, is not supported
by ADQL and must be written between double quotes if used as an identifier.

The list of SQL reserved words comes from the ADQL-2.0 standard, after removal
of all potentially used ADQL words, in order to avoid a conflict with the
already existing tokens in the ADQL grammar.

reserved word is encountered instead of a column/table/schema name/alias.

No list of ADQL reserved words has been added into the ADQL grammar.

However, the ADQL grammar has been slightly changed in order to provide a more
precise location of the REAL wrong part of the query.

Before this commit, if an ADQL reserved word (e.g. 'point') was encountered
outside of its normal syntax (e.g. 'point' no followed by an opening
parenthesis), the next token was highlighted instead of this one. Hence a
confusing error message.

For instance, the following ADQL query:

```sql
SELECT point
FROM aTable
```

returned the following error message:

> Encountered "FROM". Was expecting: "("

Now, it will return the following one:

> Encountered "point". Was expecting one of: "*" <QUANTIFIER> "TOP" [...]
> (HINT: "point" is a reserved ADQL word. To use it as a column/table/schema name/alias, write it between double quotes.)

This error message highlights exactly the source of the problem and even provide
to the user a clear explanation of why the query did not parse and how it could
be solved.

with a different local charset, the error message will print differently the
incorrect character.

and HashMap more generic by returning resp. a List and Map instead.

In the resulting SQL query, if there are an alias on the joined tables, these
aliases must be used in the ON clause (instead of the full table name).

For instance, the following ADQL query:

```sql
  SELECT *
  FROM tableA AS a NATURAL JOIN tableB AS b;
```

should be translated into the following SQL:

```sql
  SELECT *
  FROM tableA AS a
    INNER JOIN tableB AS b
      ON a.id = b.id
```

This commit complete the resolution of the Pull Request #16
(more details about the issue can be got in there)

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

The JUnit test should have been updated as well.

This infinite loop occured only when the replacement object is just
a wrapping of the matching object ; after replacement, the new object was
inspected for matching objects.

Example: infinite loop if we want to wrap all foo(...) functions with
         the function ROUND in the following query:
    SELECT foo(foo(123)) FROM myTable
	     Expected result:
    SELECT ROUND(foo(ROUND(foo(123)))) FROM myTable
	     But generated result was:
    SELECT ROUND(ROUND(ROUND(......foo(foo(123))))) FROM myTable

See the test case TestDBChecker.testClauseADQLWithNameNull() for more details.

since the commit 8e2fa9ff.

(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.

TAP capabilities resource content.

TAP capabilities resource content.

This error has been raised on the issue #32 by Zarquan.

- empty file
- not a valid VOTable document

In such cases, the following error message is returned:
  "The input file is not a valid VOTable document!"
A cause with more detais (especially the line and column numbers)
may be appended.

Cases handled with no error:

  - If the VOTable document has no rows, an empty table
    is uploaded. No error has to be returned.

  - If a row has a different number of columns than the number
    of declared FIELDs, additional values are ignored and missing
    values are replaced by NULL. This is actually nicely handled by
    STIL.

apply a quick space replacement (by %20) for few URIs of the configuration file
and remove duplicated entry (encoding) from the Gradle build script.

A special test has also been added in getFile(...) in order to deliver
a clear error message for users using a former version with URIs in their
configuration file (only for file_root_path and metadata_file).

Two embedded DBMS are used: H2 and a little SQLite. JDBC drivers are provided
in the `lib` directory. The databases are created and deleted automatically
by the JUnit tests (see `test/tap/db_testtools/DBTools for more details`).

The ANT and Gradle build scripts have been updated to reflect all these test
modifications.

ResultSetTableIterator (i.e. functions returning unknown numeric values
were not set with the right datatype but char* instead).

the automatic datatype detection was missing for CENTROID functions.
--
Additionally, some JUnit test files of the `adql` package has been moved to
the correct location.

Date and Time are converted into a string with the following resp.
formats: 'yyyy-MM-dd' and 'HH:mm:ss'.

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().

2463d5fe

sub-query. Without this information, it was impossible to resolve columns makingreference to sub-queries of the clause FROM. See the JUnit test case for a
concrete example.
(error raised by Hendrik Heinl - ARI/GAVO)

column in TAP_SCHEMA. Such names are normalized (without any prefix and without
double quotes) when getADQLName() is called, but are returned just trimmed
by getRawName(). This latter is just used by TAPMetadata when writing the XML
description of all TAP tables.